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ABSTRACT 


Today’s planning and modeling systems use two-dimensional (2D) 
representations of the three-dimensional (3D) battlespace. This presents a challenge for 
planners, commanders, and troops to understand the true nature of the battlespace. This 
thesis shows how 3D visualization can give both operation planners and executors a 
better understanding of the battlespace that can augment today’s 2D systems. Automatic 
creation of a 3D model for an amphibious operation allows the planner to view an 
operation order as a whole, from different perspectives. Recommended changes can be 
made and their effects immediately known. Warfighters can use the same tools for 
mission preparation and review. 

The United States and NATO nations use the Land C2 Information Exchange 
Data Model (LC2IEDM), formally known as the Generic Hub, as a common method for 
exchanging data between independent systems. As part of the Scenario Authoring and 
Visualization for Advanced Graphical Environments (SAVAGE) project, this research 
presents an integrated Web access and 3D visualization strategy for Department of 
Defense (DOD) tactical messaging and operation orders using the Generic Hub data 
model and the Extensible Markup Language (XML). A number of alternative yet 
consistent ways to represent an amphibious operation scenario demonstrate the power, 
flexibility and scalability of the SAVAGE approach. 
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I. INTRODUCTION 


A. PROBLEM STATEMENT 

The Extensible 3D (X3D) and Virtual Reality Modeling Language (VRML) 
graphics provide a framework for visualizing an amphibious operation in a three- 
dimensional (3D) battlespace. Work is in progress to convert standard United States 
Message Text Lormat (USMTL) documents into Extensible Markup Language-Message 
Text Lormat (XML-MTL) documents. Once done, VRML can translate the XML-MTL 
document one-step further and create an auto generated 3D scene. These 3D 
visualizations can enhance amphibious operation planning and battlespace awareness. 

B. OVERVIEW 

Joint Vision 2020 describes ways with which to make our Armed Lorces faster, 
more lethal, and more precise. It describes the significance of information superiority, 
innovation, interoperability, and precision engagement among other important 
capabilities. It recognizes that “Information superiority will enhance the capability of the 
joint force commander to understand the situation, determine the effects desired, select a 
course of action and the forces to execute it, accurately assess the effects of that action, 
and reengage as necessary while minimizing collateral damage.” (Joint Vision 2020, pg 
22) It goes on to say that “The joint force must be able to take advantage of superior 
information converted to superior knowledge to achieve ‘decision superiority’- better 
decisions arrived at and implemented faster than an opponent can react....” (Joint Vision 
2020, pg 8) This thesis aims to present an innovative, interoperable methodology for 
communicating and visualizing tactical orders that is in the spirit of Joint Vision 2020. 
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Today’s planning and modeling systems use two-dimensional (2D) 
representations of the three-dimensional (3D) battlespace. This presents a daily challenge 
for planners, commanders and troops to fully understand the true nature of the battlespace 
with regards to best ingress/egress routes, areas that offer the best cover and concealment, 
obstacles that may impede vehicular traffic, and likely enemy strongpoints or ambush 
points, to name but a few. By creating a 3D model of an amphibious operation, a 2D 
plan can be further viewed as a whole from many different perspectives. Planners can 
easily convey this information up and down the chain of command in order to solicit 
expertise and opinion. Changes can be made and their effects can be viewed and 
critiqued instantaneously, in context with spatial relationships preserved. The use of 3D 
is not intended to replace 2D maps and text-based descriptions- rather, 3D is an 
additional tool needed in combination with current techniques. 3D battlespace 
visualization may be a key enabler to achieve “decision superiority.” 

The Virtual Reality Modeling Language (VRML) and its next-generation 
specification, Extensible 3D (X3D) are Web-based graphics languages for building 3D 
models. VRML allows user interaction within a scene through viewpoint, movement, 
and rotation. One of the key features of VRML is it is an ISO standard designed for use 
over the World Wide Web (WWW). VRML has a rich set of tools for visualizing 
information. VRML graphics palettes include colors, textures, luminescence, and 
animations. These features can be combined to represent many different amphibious 
scenarios. Amphibious vehicles, ships, and troops can all be modeled. Terrain, sea state, 
and obstacles can be depicted. All of these models can interact and move through the 
virtual battlespace based on information that the planners will provide. 
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The US Message Text Format (USMTF) has been used jointly for all operational 
message traffic since the 1970’s. It includes accepted formats for countless message 
types to include operation orders and associated orders of all types. However, with the 
ongoing emphasis on development of the Extensible Markup Language (XML), the free- 
text syntax of USMTL may be reaching an end to its usefulness. The Extensible Markup 
Language (XML) provides a number of benefits over USMTL and has led the 
Department of Defense (DoD) to establish an Extensible Markup Language-Message 
Text Lormat (XML-MTL) team to focus on the translation of USMTL into XML. 

This thesis seeks to translate and synthesize USMTL-based Operation Order data 
messages written in XML into a 3D amphibious-raid within a virtual battlespace. By 
combining the power of XML and VRML, the end result will be a 3D world populated 
with aircraft, ships, amphibious vehicles, and both land and sea terrain. This virtual 
world permits the viewer to navigate through an amphibious operation in both space and 
time, and thus to observe the interactions between objects in that world. 

C. MOTIVATION 

Since World War II, the Marine Corps has made itself known as the premier 

fighting force capable of accomplishing successful amphibious operations. Iwo Jima, 

Tarawa, and the Chosin Reservoir landing are but a few reminders of the importance that 

amphibious operations have played in our nations history. While these operations were 

eventually successful, they came at the great cost of thousands of men’s lives. Were a 3D 

tool, such as this thesis introduces, available to commanders at the time these operations 

were executed, perhaps a profound impact may have been made on many life-or-death 

decisions. An approach such as this can’t change the past, but it can have a positive 

impact on the future. Not only can this technique help Marines, sailors, soldiers, and 
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airmen to train for the future, it can help both the military and the general public learn 
and possibly understand the crucial decisions and actions of the American Military, past 
and present. 

D. OBJECTIVES 

This thesis demonstrates and evaluates the functionality of a 3D amphibious 
operation visualization using Extensible 3D (X3D) and the Virtual Reality Modeling 
Language (VRML). The objective is to determine how 3D visualization can give both 
operation planners and executors a better understanding of the battlespace than is 
currently available solely using today’s 2D systems. To accomplish this objective, 
USMTL documents must first be translated into XML documents, and then the relevant 
data transformed into VRML/X3D objects. End-to-end construction of an exemplar 
amphibious-raid has guided the design and development presented here. 

E. ORGANIZATION OF THESIS 

Chapter II reviews background and related information on amphibious operations, 
US Message Text Format (USMTF), Extensible Markup Language-Message Text Format 
(XML-MTF), Combat 21, and operation and air tasking orders. Chapter III describes the 
amphibious-raid scenario and introduces operation order design and content. It also 
introduces the scenario exemplar operation orders and discusses potential limitations. 
Chapter IV provides insight into the NATO Land Command and Control Information 
Exchange Data Model (LC2IEDM). Chapter V discusses the importance of using a Web- 
based approach and the Extensible Markup Language (XML). The XML schemas for the 
operation orders and ongoing efforts to further Web based technologies are also 
presented. Chapter VI describes the scenario and visualization techniques upon which 
the virtual amphibious-raid is based. Chapter VII discusses scenario-authoring 
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methodologies, assumptions and limitations, and presents the results of the virtual 
amphibious-raid. Chapter VIII summarizes the conclusions and recommendations for 
future work of this thesis. The appendices present the exemplar operation orders, 
schemas, stylesheet, and scripted raid code. 
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II. BACKGROUND AND RELATED WORK 


A. INTRODUCTION 

This chapter reviews concepts that are at the root for understanding Marine Corps 
amphibious operations. Subject matter includes amphibious operations background, 
Operation and Air Tasking Orders, and the US Message Text Format (USMTF). 

B. AMPHIBIOUS OPERATION 

1. Definition 

An amphibious operation is, 

.. .an attack launched from the sea by naval and landing forces, embarked 
in ships or craft involving a landing on a hostile shore. (Joint Publication 
1 - 02 ) 

It is important to note here that the attack must be launched from the sea, and that the 
landing be made on a hostile shore. Without these two elements, there is no amphibious 
operation. 

2. Types of Operations 

There are four types of amphibious operations that Marines may be called upon to 
perform. These include the amphibious assault, amphibious-raid, amphibious 
demonstration, and amphibious withdrawal. 

An amphibious assault is the principal type of amphibious operation. It is usually 
long in duration and seeks to establish large landing forces on a hostile shore. An 
amphibious-raid is similar to an assault, except that it is generally short in duration and 
has a planned withdrawal. Raids may be used for reconnaissance, diversions, 
evacuations, or as a means to quickly inflict loss or damage on the enemy, to name a few. 
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An amphibious demonstration seeks to deceive the enemy with a show of force, and 
hopes to cause him to adopt an unfavorable course of action. There is not an actual 
landing during a demonstration. At a predetermined turn-away point, the forces will turn 
around with the hope that the desired effect has been accomplished. Finally, an 
amphibious withdrawal is usually made at the end of an operation or when it is 
strategically or tactically determined to be a necessity. It is not predetermined, and is one 
of the more difficult types of operation. (AWS Ex Ops Course, Vol. 1, pg. 2-16 -2-17) 

3. Marine Air Ground Task Force (MAGTF) 

There are three basic and one special MAGTF types in the Marine Corps. Each 
type consists of a command element (CE), ground combat element (GCE), air combat 
element (ACE), and a combat service support element (CSSE). 

a. Marine Expeditionary Force (MEF) 

The MEF is the principal warfighting MAGTF. It can conduct 
amphibious operations as well as sustained operations ashore. It typically deploys with 
supplies that are geared to last 60 days. In addition to the CE, the MEF is comprised of a 
a reinforced division (GCE), a Marine aircraft wing (ACE), and a force service support 
group (FSSG) which serves as the CSSE. 

b. Marine Expeditionary Unit (MEU) 

A MEU is usually deployed at sea in an amphibious ready group (ARG), 

and takes along supplies aimed at sustaining it for 15 days of continuous operations 

should it be called to do so. The MEU serves as a forward presence or projection of 

power, and can provide immediate response to a crisis or contingency through its 

capability of rapid deployment. The MEU acts as an advance force for a larger MAGTF 

to follow if the duration of the operation exceeds 15 days. In addition to the CE, the 
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MEU is comprised of a reinforced infantry battalion (GCE), a reinforced medium 
helicopter squadron (ACE), and a MEU service support group (MSSG) which serves as 
the CSSE. 

c. Marine Expeditionary Unit Special Operations Capable (MEU(SOC)) 

MEU(SOC) is a certification that all MEUs attempt to obtain prior to 

deployment. A series of special operations capable exercises (SOCEX) are conducted in 
which the MEU demonstrates the ability to conduct varied special operations such as 
non-combatant evacuation operations (NEOs), hostage rescue, demolition operations, and 
civic action operations to name a few. MEU(SOC) composition is similar to that of a 
MEU except that it is augmented with specialized personnel and equipment. 

d. Special Purpose MAGTF (SPMAGTF) 

SPMAGTFs are configured to accomplish a specific mission when one of the 
other MAGTF types is inappropriate or too large to employ. They can be organized, 
trained and equipped to conduct a variety of operations. In addition to the CE, the 
SPMAGTF is normally comprised of at least a platoon-sized element (GCE), and a task 
organized ACE and CSSE. (AWS Ex Ops Course, Vol. 1, vs. ID-8 and 9) 

C. AMPHIBIOUS PLANNING DOCUMENTS 

1. Operation Order (OPORD) 

The Operation Order (OPORD) is a directive issued by a commander to 
subordinate commanders for the purpose of effecting the coordinated execution of an 
operation. (DoD Definition). OPORDs are written at all levels of command by all 
military services. One high-level OPORD can in turn generate numerous like OPORDs 
down to the unit-level. The format is generally the same, with detail increasing as the 
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order reaches the lowest unit. Operation orders are discussed in more detail in Chapter 

m. 

2. Air Tasking Order (ATO) 

The Air Tasking Order (ATO) is used to task and disseminate information to units 
regarding projected sorties, capabilities, and specific missions. It commonly provides 
instructions regarding call signs, targets, aircraft type/number, controlling agencies, and 
other general information. 

Automatically generating an Air Tasking Order and visualizing it in 3D was the 
subject of Mark Murray and Jason Quigley’s thesis, “Automatically Generating A 
Distributed 3D Battlespace Using USMTF and XML-MTF Air Tasking Order, Extensible 
Markup Language (XML) and Virtual Reality Modeling Language (VRML)”, June 2000 
at the Naval Postgraduate School. The proof-of-concept demonstration in that effort 
provided the basis for this work. 

D. US MESSAGE TEXT FORMAT (USMTF) 

The US Message Text Format (USMTF) is the joint standard for message-based 
information exchange. It facilitates communications efficiency for joint and combined 
forces by standardizing message formats, data elements, and information exchange 
procedures, (www- usmtf.itsi.disa.mil) 

USMTF is a government proprietary message standard for sharing structured 
information (Edwards, 1999, slide 4). It has the advantage of having approval from all 
DoD agencies and US allies. USMTF represents a large collection of Information 
Exchange Requirements that provide a standard vocabulary, are platform independent 
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and man readable. Additionally, joint and international configuration-management 
processes support USMTF. (Edwards, 1999, slide 6) 

While USMTF is still being used throughout the DoD, it has many limitations and 
some believe it is coming to the end of its useful life. With the proliferation of the 
Extensible Markup Language (XML) and the shortcomings of USMTF, there is a strong 
push in the DoD to develop a new standard called Extensible Markup Language-Message 
Text Format. 

1. Extensible Markup Language-Message Text Format (XMLrMTF) 

USMTF has several downsides that make it less appealing as technology 
continues to advance. For one, USMTF is a military proprietary piece of software. This 
forces the government to upkeep and upgrade all aspects of USMTF, precluding any 
commercial-off-the-shelf (COTS) support. It also requires the government to hire system 
developers who will have to learn and adopt USMTF standards in order to engineer 
interfaces. Because government-off-the-shelf (GOTS) tools are expensive and lag far 
behind the competitive COTS market, USMTF is becoming a high-priced dinosaur. 
(Edwards, 1999, slide 7) 

Another shortcoming to USMTF is its formatting rules. It was developed in the 
early 1970’s for AUTODIN transport and teletype presentation; therefore, USMTF 
format is limited to display only teletype characters (capital letters and numbers). 
(Edwards, 1999, slide 7) Given the vast number of fonts, formats, and the addition of 
multi-media available in today’s presentations, USMTF is somewhat archaic. 

Finally, USMTF can only send messages, not metadata. Metadata can be defined 
as data about data. That is, it contains a description or information on the data being sent. 


11 



Metadata provides powerful utility in that individual consumers can search, filter, 
organize, or otherwise manipulate data in such a way as to provide meaning that is in line 
with personal or organizational guidelines. 

In order to try and overcome many of these limitations, an initiative called the 
Extensible Markup Language-Message Text Format (XML-MTF) was launched. In May 
of 1999, the XML-MTF Development Team was formed to attempt replacing standard 
USMTF with XML formatted messages. The team’s charter was to develop an XML- 
MTF specification and software tools that transform messages between USMTF and 
XML-MTF standards. This approach has numerous advantages. XML gives users the 
ability to manipulate data in any way they see fit, as it includes metadata. 

Interoperability issues can be overcome because XML is easily exchanged between 
systems. These systems can, in turn, transform the data using an Extensible Stylesheet 
Language (XSL) into any format necessary. Additionally, since XML is an open Web 
standard, USMTF won’t be tied to a government proprietary standard any longer. This 
will allow XML-MTF to keep pace with technology as well as have a learned group of 
commercial technicians available, who won’t have to overcome a steep learning curve 
whenever XML-MTF changes or updates need to be made. 

According to the J6I, “...this powerful combination of military and industry 
standards, called XML-MTF, is expected to drastically improve the warfighter’s ability to 
find, retrieve, process and exchange tremendous amounts of information easily across 
system, organizational and format boundaries....” (Edwards, 1999, slide 10) 
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E. COMBINED ARMS ANALYSIS TOOL FOR THE 21 st CENTURY 

(COMBAT XXI) 

The Combined Arms Analysis Tool for the 21 st Century (COMBAT XXI) is a 
non-interactive, high-resolution analytical combat simulation system being developed by 
the US Army and US Marine Corps. The COMBAT XXI model incorporates both land 
and amphibious warfare capabilities, and is designed to evaluate operations at the brigade 
level and below. Among its goals are interoperability with other models and systems, 
plus alleviation of the difficulties that legacy systems experience in the scenario- 
development process. (Goerger, 2001) 

COMBAT XXI adopted an open standard called the High Level Architecture- 
Dynamic Scenario Builder (HLA-DSB) to handle the problem of portability. This 
standard prescribes a basic format for scenario files, and uses the Extensible Markup 
Language (XML) as the storage and interchange media. (Goerger, 2001) By using 
XML, COMBAT XXI will reap the same benefits as those of XML-MTL. 

F. SUMMARY 

This chapter covered concepts and technologies inherent to understanding 
amphibious operations. An amphibious operation is an attack that must be launched from 
the sea against a hostile shore. The four types of amphibious operations are: amphibious 
assault, amphibious-raid, amphibious demonstration, and amphibious withdrawal. A 
Marine Air Ground Task Force (MAGTF) is responsible for executing an amphibious 
operation and varies in size and structure depending on the type and duration of the 
operation. The Marine Expeditionary Force (MEF) is the principal warfighting MAGTF 
while the Marine Expeditionary Unit Special Operations Capable (MEU(SOC)) is the 
primary forward presence. 
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The Operation Order, which includes the Air Tasking Order, is the formal and 
primary means of effecting the coordinated execution of an operation. These orders are 
currently written using the United States Message Text Format (USMTF), but are 
currently being rewritten using the Extensible Markup Language (XML). The resulting 
Extensible Markup Language-Message Text Lormat (XML-MTL) is expected to provide 
more robust and interoperable data that is more valuable to the end users. The Combined 
Arms Analysis Tool for the 21 st Century (COMBAT XXI) is a non-interactive, high- 
resolution analytical combat simulation system that incorporates land and amphibious 
warfare capabilities. Like many tools currently being developed, COMBAT XXI seeks 
to leverage the robust benefits of XML. Together, these technologies can lead to an 
integrated “system of systems” wherein interoperability issues between services and 
countries are non-existent. 
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ID. OPERATION ORDERS AND TACTICAL MESSAGING 


A. INTRODUCTION 

This chapter focuses on the amphibious invasion scenario and the operation 
orders that accompany it. It describes the elements of an operation order and further 
discuss the methodology and limitations of the operation order as it is applied to the 
amphibious scenario. Finally, it examines Public Beta Release 1.02 of the MTF2XML 
converter. 

B. AMPHIBIOUS INVASION DESCRIPTION 

This section presents an imaginary exemplar scenario: Continued fighting in 
Koala between Snake National Forces and Apean Separatists has resulted in the 
displacement of thousands of Koalan non-combatants. The non-combatants have 
attempted to flee towards the Apean and Monkey borders which has caused heightened 
tensions along the Apean/Koalan border. To support peacekeeping operations along the 
border, a forward-operations base is required in Ape. While the Apean Government 
supports establishment of the airfield, the likely reaction of the civilian population is 
unknown. 

Combined Joint Task Force Blue has assembled off the shore of “Red Beach” in 
preparation for an amphibious-raid (Figure 3.1). Marine Forces will disembark 
Amphibious Ready Group (ARG) shipping using Advanced Amphibious Assault 
Vehicles (AAAVs) under cover of darkness to storm “Red Beach” and proceed inland to 
secure the airfield (Figure 3.2). Marine AH- 1Z Super Cobras will provide cover and 
support for raiding forces. A destroyer squadron will steam offshore in order to defend 
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the ARG and provide fire support for the raid. In addition to surface fleet support, one 
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Figure 3.1 Naval Ships Assembled off the Shore of “Red Beach’ 



Figure 3.2 AAAV Route to Airfield Represented As Waypoints 
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Once Marine Forces have secured the airfield, they will remain in position until 



Army Apache helicopters arrive and assume control (Figure 3.3). At that time, all 
Marine Forces will return to ARG shipping for completion of the mission. 


Figure 3.3 Marine Security Positions at Camp Pendleton Airfield 


C. OPERATION ORDER DRAFTING AND DESIGN 

In order to capture all of the pieces of the amphibious-raid above, it is necessary 
to put the information together in a meaningful format. The operation order is the format 
of choice. As noted in Chapter II, an operation order is a directive issued by a 
commander to subordinate commanders for the purpose of effecting the coordinated 
execution of an operation. While the operation order is the primary directive, some 
information may be put in other meaningful formats that are referenced in the order. 
These documents may consist of annexes, standard operating procedures (SOPs), 
operation overlays, or other orders. 


17 














All operation orders have guidelines that are followed when they are written. 
“Guidelines” is a key word here because, while all operation orders follow the same 
format, the style they are written in, information that is included or omitted, and the 
amount of detail may be vastly different from one order to the next. That said, all 
operation orders have a heading, a body and an ending that consist of similar information. 
The Amphibious Warfare School provides an in-depth look at operation order writing and 
contents online. There is a self-paced text entitled Operation Plans and Orders that can 
be accessed via the following link: http://www.mcu.usmc.mil/aws/selfpacedText The 
next pages focus on each of the sections and provide a brief description of the 
information they contain. 

1. Heading 

Heading data contains basic routing information. It is used to handle the 
administrative details of the order. It generally includes the message classification; who 
the message is from; who the message is to; the date/time group (DTG); a message 
reference number; the title of the order; references referred to in the order; and the time 
zone that will apply during the execution of the order. 

2. Body 

The body of the operation order contains the meat of the information needed to 
execute the mission. There are five paragraphs within the body of the order that are 
further broken down into standard subparagraphs. 
a. Situation 

This paragraph is made up entirely of information that is designed to 
provide the framework for the operation. It is divided into six subparagraphs: 1) General, 
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2) Battlespace, 3) Enemy Forces, 4) Friendly Forces, 5) Attachments and Detachments, 


and 6) Fegal Considerations. 

(1) General. Used to describe the political and military 
environments that may set the conditions for execution of 
the mission. It is often omitted in OPORDS. 

(2) Battlespace. Used to describe the higher commander’s 
area of operations and the command’s area of interest and 
operations. 

(3) Enemy Forces. Used to describe enemy information 
that may have an effect on mission accomplishment. This 
information may be alluded to in an annex or other 
document. If it is included in this paragraph, information is 
given in the following order: 1) Composition, Focation, 
Disposition, and Movements, 2) Capabilities, 3) Enemy 
Courses of Action (most likely and most dangerous), 

(4) Friendly Forces. Used to describe friendly forces that 
may have a bearing on the outcome of the operation. This 
may include the location, mission, and intent of higher, 
adjacent or supporting forces. 

(5) Attachments and Detachments. Used to describe non- 
organic units that have been attached to, or organic units 
that have been detached from, the headquarters that are 
issuing the order. Often this will read “None.” 
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(6) Legal Considerations. Used to describe only significant 


conditions on which the OPORD is based. This paragraph 
is routinely omitted. 

b. Mission 

This paragraph is used to give a succinct account of the WHO, WHAT, 
WHERE, WHEN, and WHY of an operation in order to have enough information for 
coordination and compliance. It does not describe the HOW. 

c. Execution 

This paragraph is probably the most important of the entire operation 
order. It describes HOW the mission will be accomplished. It contains six 
subparagraphs: 1) Commander’s Intent, 2) Concept of Operations, 3) Tasks, 4) Reserves, 
5) Commander’s Critical Information Requirements (CCIR), and 6) Coordinating 
Instructions. 

(1) Commander’s Intent. Used to describe the 
commander’s personal articulation of the purpose of the 
operation. It is extremely important because, in the event 
of unforeseen circumstances, the intent will guide 
subordinates to use proper judgment and initiative to 
deviate from the plan, yet remain consistent with the 
objectives of the commander. 

(2) Concept of Operations. This is a summary statement of 
HOW the commander wants the operation to unfold. In 
some cases, the Concept of Operations may refer to other 

documents, or be an entire appendix of its own. 
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(3) Tasks. Used to assign tasks to subordinate elements. 
This paragraph is where each element is told what its 
specific mission is with regards to accomplishing the 
overall mission. Assignments are given to ground 
elements, aviation elements, and service support elements, 
in that order. 

(4) Reserve. Used to assign the mission of the reserve 
forces. 

(5) Commander’s Critical Information Requirements 
(CCIR). Used to describe both friendly and enemy 
information that the commander considers critical for 
situational awareness and future planning. 

(6) Coordinating Instructions. Used to “send home” 
information that is applicable to everyone affected by the 
order. Information may include, but is not limited to, D- 
day, H-hour, L-Hour, and coordinates for beach landing 
sites, helicopter landing zones, and amphibious task force 
objectives. 

d. Administration and Logistics 

This paragraph describes personnel and logistical information important to 
the conduct of the operation. It contains seven subparagraphs that are described in the 
following order: 1) Personnel, 2) Logistics, 3) Public Affairs, 4) Civil Affairs, 5) 
Meteorological and Oceanographic Services, 6) Geospatial Information and Services, and 


7) Medical Services. Each of these subparagraphs may be referenced to a SOP, or more 
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commonly, its appropriate annex. At the tactical level, subparagraphs 1 and 3-7 are 
routinely omitted. 

(1) Personnel. Used to give instructions on timely and 
accurate strength and accountability reporting procedures. 

(2) Logistics. Used to describe how logistics support such 
as transportation, resupply, maintenance, and general 
engineering will be conducted. 

(3) Public Affairs. Used to give instructions on how to 
deal with questions from the local media. 

(4) Civil Affairs. Used to give instructions on how to 
handle issues such as requests for political asylum or 
temporary refuge. 

(5) Meteorological and Oceanographic Services. Used to 
describe weather, tide, and other environmental factors that 
may have an impact on operations. Also discusses how this 
information will be updated. 

(6) Geospatial Information and Services. Used to describe 
the use and update of satellite imagery. 

(7) Medical Services. Used to describe the locations of 
hospitals and battalion aid stations, their hours and services 
offered, and to give instructions on medevac procedures. 
Anything medically related may go here, but will most 
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likely be in a separate annex or covered in a separate CSSE 
order. 

e. Command and Signal 

This is the last paragraph in an operation order, and is used to provide 
instructions on the proper establishment and maintenance of command and signal. It is 
subdivided into four paragraphs: 1) Command Relationships, 2) Command Posts and 
Headquarters, 3) Succession to Command, and 4) Signal. 

(1) Command Relationships. Generally used in a large or 
complex operation in order to easily ascertain “who is 
who” with regards to command interaction. Is routinely 
omitted or referenced to its appropriate annex. 

(2) Command Posts and Headquarters. Used to give 
command post locations of the orders issuing unit and those 
of subordinate and higher units when known or desired. 

(3) Succession to Command. Used to describe who will 
take over command should the current commander become 
incapacitated for any reason. This list needs to be deep 
enough to ensure there is never a question as to who is in 
command if there needs to be numerous successions. 

(4) Signal. Used to describe the use and meaning of 
electronic communications, pyrotechnics, and other 
communication means. 
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3. Ending 

Ending data is really just a continuation of administrative information such as 
contained in the Heading. It generally contains the message classification, and may 
contain an authentication, list of annexes used, and a request for acknowledgement. 

D. OPERATION ORDER METHODOLOGY 

There were two overarching goals in writing the exemplar operation orders for 
this thesis. The first is that the operation be joint. The orders needed to contain elements 
of Marine Corps, Navy and Army missions (at a minimum) in order to show that 
operation order visualization can work for all services. The second goal was that the 
operation had to be realistic. Not only did the “story” have to seem real, but the tactics, 
players and equipment needed to make sense as well. To make this happen, an 
operational scenario considered for Operation Noble Anvil/Allied Force was used and 
“rewritten” to take place off of Camp Pendleton’s “Red Beach” using surface and sub¬ 
surface ships from the West Coast and Hawaii. Amphibious tactics and doctrine were 
drawn from experience and from the Amphibious Warfare School Non-Resident Program 
textbooks. 

Appendices B through F contain the operation orders drafted for this scenario. 
Appendix B is the top-level joint order. Appendix C is a lower-level operations annex. 
Appendices D through F are varying versions of the unit-level (specifically GCE) orders. 
These orders were written with enough detail and structure to fulfill the intent of this 
thesis. Some of the less-pertinent guidelines mentioned earlier have not been adhered to, 
and much superfluous information has been omitted or is incomplete in order to focus on 
operation order tactical details critical for visualization. As this thesis seeks to visualize 
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an amphibious-raid, its focus is on the unit-level operation order (Appendices D through 
F). Therefore some of the coordinates for AORs, FSAs and NFAs in the joint order and 
operation annex do not correspond to the AOR the scenario encompasses. These 
coordinates are provided as “filler” and have no bearing on the outcome of this thesis. 

The following paragraphs briefly discuss the methodology for the unit-level order, 
and the clarifying simplifications that were taken to refine it along the way. The 
methodology is summarized in Appendix H. This summary also introduces the Generic 
Hub (GH), which is discussed in detail in Chapter IV. 

1. Unit Operation Order as a Word Document 

While USMTF is the DoD standard for sending messages, it is an extremely 
common practice (at least in the Marine Corps, and conjecturally in other services) to 
write orders as a Word document and distribute copies (paper or e-mail) to the 
appropriate recipients. This is why the “first draft” of the unit order is provided as a 
Word document. 

Figure 3.4 is the TASKS section of the order (the complete order can be found in 
Appendix D). This portion communicates enough detail for tasked units to understand 
the commander’s intent and be able to write five paragraph orders of their own that 
further describe the tasks of the individual components (platoon, squad, fire team, etc.). 

It also demonstrates the desire to keep the initial assault small and simple. It is not an 
oversight that an entire reinforced platoon is not likely to fit into a single Advanced 
Amphibious Assault Vehicle (AAAV). This was an intentional inaccuracy in order to 
keep the amount of AAAVs to be visualized at a minimum. As the ability to visualize 
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more complex scenarios and the number of available models grows, future work should 
expand upon this scenario and add more realistic levels of detail. 


B. TASKS 

1. 1 st PLAT (REIN), CO A 

i. A H-HOUR (1500Z), CONDUCT AN AAAV ASSAULT ACROSS RED 
BEACH AND CONTINUE INLAND TO SEIZE ATF OBJECTIVE A. 

ii. YOU ARE THE RECONNAISSANCE ELEMENT AND WILL LOAD IN 
AAAV 1. 

iii . ONCE YOU REACH THE BLS, YOU WILL FOLLOW IN TRACE OF 2 nd 
AND 3 rd PLATOONS WHILE DRIVING TO ATF OBJECTIVE A. 
iv. UPON CONSOLIDATION ON ATF OBJECTIVE A, ESTABLISH 

PERIMETER SECURITY IN THE VICINITY OF GRID 11SMG673842 
v. BE PREPARED TO ASSIST WITH THE TURNOVER TO TF APACHE. 

2. 2 nd PLAT (REIN), CO A 

i . AT H-HOUR, CONDUCT AN AAAV ASSAULT ACROSS RED BEACH AND 
CONTINUE INLAND TO SEIZE ATF OBJECTIVE A. 
ii. YOU ARE THE COMMAND ELEMENT AND WILL LOAD IN AAAV 2. 

iii. ONCE YOU REACH THE BLS, YOU WILL FOLLOW IN TRACE OF 3 rd 
PLATOON WHILE DRIVING TO ATF OBJECTIVE A. 

iv. UPON CONSOLIDATION ON ATF OBJECTIVE A, ESTABLISH 

PERIMETER SECURITY IN THE VICINITY OF GRID 11SMG664839. 

v. BE PREPARED TO ASSIST WITH THE TURNOVER TO TF APACHE. 

3. 3 rd PLAT (REIN), CO A 

i . AT H-HOUR, CONDUCT AN AAAV ASSAULT ACROSS RED BEACH AND 
CONTINUE INLAND TO SEIZE ATF OBJECTIVE A. 
ii. YOU ARE THE SECURITY ELEMENT AND WILL LOAD IN AAAV 3. 
iii. UPON CONSOLIDATION ON ATF OBJECTIVE A, ESTABLISH 

PERIMETER SECURITY IN THE VICINITY OF GRID 11SMG676853. 


Figure 3.4 Unit Operation Order TASKS Section excerpted from Appendix D 


2. USMTF “Enhanced” Order 

The next step in automatically generating a 3D visualization of the operation 
order was to reformat the Word document into the United States Message Text Format. 
This was necessary in order to run the XML2MTF tool on the order to get it into an XML 
format. This was a relatively easy step, but it became very apparent that there was not 
enough tactical information provided. In order for the AAAYs to move in a virtual 
world, they would have to have some idea of where to go, when to go, and when to stop. 
While the traditional operation order would not get to this level of detail (except perhaps 


in an annex or landing plan), it was concluded that it was necessary to add information to 
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the order. After adding the new information and running it through the XML2MTF tool, 
it became evident that the tool did not distinguish this information from the rest of the 
general text. Knowing this, liberties were taken with the structure of the TASKS section 
of the order to make defining tags and writing an XML schema easier. XML schemas are 
discussed in Chapter V. Figure 3.5 emonstrates some of the clarifying changes that were 
made (the complete order can be found in Appendix E). 

Most notably, an Organization section and a Timeline and Movement section 
were added. In the Organization section, each AAAV was given a call sign for easier 
identification. The original tasks given to each platoon were modified to read “per 
guidance in section 6 of this order.” Section 6, which is the Timeline and Movement 
section, then became the heart of the order with regards to important data required for the 
3D visualization. It now contains all the necessary data that the AAAVs need to move. 
Start times and locations, end times and locations, waypoints, and actions at the objective 
are given for each phase of the assault (insertion, infiltration, maneuvers at the objective, 
and exfil). Currently, for sake of simplicity, all AAAV movement is tied to the lead 
vehicle with the exception of movement at the objective. In other words, the lead AAAV 
dictates the movement of the other AAAVs while moving from ship-to-shore, and to and 
from the airfield. In order to give each AAAV autonomous movement, additional 
coordinates must be given for each vehicle in every phase of the assault. 

Finally, all coordinates are given in terms of Lat/Long because they are universal 
and don’t change. To depict land coordinates by grid numbers, the type and version of 
the map being used must be specified, and the conversion program would have to know 
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how to do the translation. This feature is very important and may possibly be added by 
writing a script for it, however, Lat/Long suffices for purposes of this thesis. 

B. TASKS 

1. ORGANIZATION 

1. AAAVI 

A. CALL SIGN - BLUE DEVIL 
4. 3RD PLAT(REIN), CO A 

A. AT H-HOUR, CONDUCT AN AAAV ASSAULT ACROSS RED BEACH AND 
CONTINUE INLAND TO SEIZE ATF OBJECTIVE A PER GUIDANCE IN SECTION 6 
OF THIS ORDER. 

6. TIMELINE AND MOVEMENT 

A. DEPART SHIP AT H-HOUR (INSERTION) 

1. START TIME: 041500ZJUL01 

2. START LOCATION: LAT N33DEG11.OOMIN LONG W117DEG35.OOMIN 

3. END TIME: 041800ZJUL01 

4. END LOCATION: LAT N33DEG14.9MIN LONG W117DEG25.7MIN 

B. TRANSIT TO OBJECTIVE AREA (INFIL) 

1. START TIME:041801ZJULO1 

2. START LOCATION: LAT N33DEG14.9MIN LONG W117DEG25.7MIN 

3. WAYPOINTS: 

A. LAT N33DEG15.538MIN LONG W117DEG24.875MIN 

B. LAT N33DEG13.976MIN LONG W117DEG23.328MIN 

C. LAT N33DEG17.274MIN LONG W117DEG22.241MIN 

4. END TIME: 042100ZJUL01 

5. END LOCATION: LAT N33DEG17.885MIN LONG W117DEG21.144MIN 

Figure 3.5 USMTF “Enhanced” Operation Order Demonstrating Changes in the 
TASKS Section excerpted from Appendix E 
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Table 3.1 summarizes the changes that were made to the enhanced order. The 
‘(new)’ under the Sub-paragraph heading signifies and additional sub-paragraph with 
supplementary information. 


Section 

Sub-paragraph 

Additional Information 

Tasks 

Organization (new) 

Call signs for each AAAV 


Platoon Assignments 

Modified original verbiage 
to include reference to sub- 
paragraph 6 of the order 


Timeline and Movement 
(new) 

Insertion- start/end times 
and start/end locations 



Infil- start/end times and 
start/end locations as well 
as a series of waypoints 

Actions at the Objective- 
start/end times and location 
of each AAAV 



Exfil- start/end times and 
start/end locations as well 
as a series of waypoints 

Extraction- start/end times 
and start/end locations 


Table 3.1 Summary of Changes to the USMTF “Enhanced” Operation Order 
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3. XMI^MTF Order 


Once the unit-level order was in the USMTF system, it was possible to run the 
XML2MTF conversion tool on it. Figure 3.6 demonstrates that the tool did a good job of 
“pulling out” administrative information such as the exercise name and the originator of 
the order. However, Figure 3.7 shows that the tool takes the GENTEXT data and lumps 
it all together. It is evident that the information is part of the EXECUTION section of the 
order, but the data within the section is very ambiguous and not very useful. Because of 
this, an XML schema that can semantically capture this data had to be developed. The 
XML schema is discussed further in Chapter V. The complete XML-MTF order can be 
found in Appendix F. 


<?xml version="1 . 0"?> 

-<order> 

-<exercise_identification setid="EXER"> 
<exercise_nickname>XML01</exercise_nickname> 

</exercise_identification> 

-<message_identification setid="MSGID"> 

<message_text_format_±dentitier>ORDER</message_text_format_identitier> 
<or±ginator>BLT ONE SLANT FOUR</originator> 

</message_identification> 

_< type_of_order setid="ORDTYP"> 

<type_of_plan_order>TASKORD</type_of_plan_order> 

<order_originator_and_or_number/> 

</type_of_order> 

-<time_zone setid="TIMEZONE"> 

<time_zone_zulu>Z</time_zone_zulu> 

</time_zone> 


Figure 3.6 XML-MTF Operation Order Showing Capture of Administrative 
Information excerpted from Appendix F 
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-<general_text_information set±d="GENTEXT"> 

<gentext_text_indicator>EXECUTION</gentext_text_indicator> 
<free_text xml: space="preserve"> ...B. TASKS 1. ORGANIZATION A. 
AAAV COMPANY 1. AAAVI A. CALL SIGN - BLUE DEVIL 2. AAAV 2 A. 
CALL SIGN - NITTANY LION 3. AAAV 3 A. CALL SIGN - HUSKY 2. 1ST 
PLAT(REIN), CO A AT H-HOUR (1500Z), CONDUCT AN AAAV ASSAULT 
ACROSS RED BEACH AND CONTINUE INLAND TO SEIZE ATF OBJECTIVE A 
PER GUIDANCE IN SECTION 6 OF THIS ORDER. PER GUIDANCE IN 
SECTION 6 OF THIS ORDER, WITHDRAW TO ARG SHIPPING AFTER TF 
APACHE ASSUMES CONTROL OF THE AIRFIELD. C. YOU ARE THE 
RECONNAISSANCE ELEMENT AND WILL LOAD IN AAAV 1. 3. 2ND 

PLAT(REIN), CO A A. AT H-HOUR, CONDUCT AN AAAV ASSAULT ACROSS 
RED BEACH AND CONTINUE INLAND TO SEIZE ATF OBJECTIVE A PER 
GUIDANCE IN SECTION 6 OF THIS ORDER. B. PER GUIDANCE IN 
SECTION 6 OF THIS ORDER,WITHDRAW TO ARG SHIPPING AFTER TF 
APACHE ASSUMES CONTROL OF THE AIRFIELD. C. YOU ARE THE COMMAND 
ELEMENT AND WILL LOAD IN AAAV 2. 4. 3RD PLAT(REIN), CO A A. AT 

H-HOUR, CONDUCT AN AAAV ASSAULT ACROSS RED BEACH AND CONTINUE 
INLAND TO SEIZE ATF OBJECTIVE A PER GUIDANCE IN SECTION 6 OF 
THIS ORDER. B. PER GUIDANCE IN SECTION 6 OF THIS ORDER, 
WITHDRAW TO ARG SHIPPING AFTER TF APACHE ASSUMES CONTROL OF 
THE AIRFIELD. C. YOU ARE THE SECURITY ELEMENT AND WILL LOAD IN 
AAAV 3. 5. BLT RESERVE: CO B A. AT H-HOUR, YOU ARE ON 
IMMEDIATE ALERT AND WILL BE PREPARED TO ASSUME THE MISSION OF 
THE MAIN EFFORT. 6. TIMELINE AND MOVEMENT A. DEPART SHIP AT H- 
HOUR (INSERTION) 1. START TIME: 041500ZJUL01 2. START 
LOCATION: LAT N33DEG11.OOMIN LONG W117DEG35.0OMIN 3. END TIME: 
0 418 00ZJULO1 4. END LOCATION: LAT N33DEG14.9MIN LONG 
W117DEG25.7MIN B. TRANSIT TO OBJECTIVE AREA (INFIL) 1. START 
TIME:041801ZJUL01 2. START LOCATION: LAT N33DEG14.9MIN LONG 
W117DEG25.7MIN 3. WAYPOINTS: A. LAT N33DEG15.538MIN LONG 
W117DEG24.875MIN B. LAT N33DEG13.976MIN LONG W117DEG23.328MIN 
C. LAT N33DEG17.274MIN LONG W117DEG22.241MIN 4. END TIME: 

0 4 2100ZJULO 1 5. END LOCATION: LAT N33DEG17 .MIN... </free_text> 
</general_text_information> 


Figure 3.7 XML-MTF Operation Order Showing GENTEXT Data in Unusable 

Format excerpted from Appendix F 


E. OPERATION ORDER LIMITATIONS 

While the benefits of being able to compose an operation order and visualize the 
plan are enormous, there are many limitations to using operation orders for this purpose. 
This section addresses some of the problems that need to be overcome in order to make 
widespread use of a tool like this. 
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1. Inconsistent Applications 

When it comes to writing orders, there are inconsistent applications regarding 
their use both across and within the military services. One service’s operation order may 
be another’s warning order, which may be yet another’s fragmentary order. Each can 
contain similar information, but is written differently and varies in the level of detail. It 
is up to individuals to decide what type of order to write. Additionally, guidelines for 
writing orders are often misinterpreted or misunderstood. One order may omit key 
information that the next order includes. No automatic completeness checks are currently 
available. There is no “hard and fast” doctrine regarding what must be included in an 
order. Guidelines are subject to the interpretation of the individual, which results in 
many like orders with individual styles that make them very different. While this is not a 
showstopper, until there are XML DTDs or schemas for every possible type of order, 
visualization capabilities are going to rely on everyo ne using a standard operation order 
with identical types of information. 

2. Acronyms 

Personnel in the armed services know what it is l ik e to live in an ARE (acronym 
rich environment)! There are likely as many acronyms as there are hours in a year, and 
many have multiple meanings (including acronyms in an acronym!). It is very difficult to 
define a tagset that understands an acronym in a way that can be useful if they are used 
haphazardly. While it is not likely that the use of acronyms will ever end, their 
usefulness in an operation order is questionable. Overuse of acronyms that are not 
understood by an XML DTD/schema, or (even more distressing) the recipient of the 
order can render a visualization tool ineffective. 
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3. Inconsistent Semantics 


The armed services pride themselves on being unique from one branch to the 
next. Oftentimes, the same philosophy holds true with individual units or specialties in 
the same service. What this valuable uniqueness also tends to encourage is a lot of 
different terms or meanings (semantics) for the same thing. For instance, the Marine 
Corps wears “cammies” while the Army wears “BDUs”. While a Sergeant in the Marine 
Corps is just that, the term is used very loosely in the Army. An E-3 isn’t the same thing 
in any of the services. So how does one go about defining XML tags when there are so 
many differences? One way would be to have different tags for each service. In this 
way, service unique definitions would not be an issue. However, what terminology needs 
to be used on a joint order, or during an allied or coalition exercise? One possible 
solution to jargon incompatibilities is the Land Command and Control Information 
Exchange Data Model (LC2IEDM). This database model has been accepted by the 
United States and NATO, and is discussed at length in Chapter IV. 

4. Applicability 

Another limitation with regards to the written operation order is that it is not used 

consistently at all levels in the chain of command. Often times written orders come from 

high commands and get disseminated through the lower echelons in numerous ways. It is 

not unheard of (and probably a common practice) for the amphibious-raid scenario 

presented in this thesis to not be written as an operation order at all but rather covered in 

a confirmation brief. Squad leaders might scribble partial five-paragraph orders on the 

main course box of the Meal Ready to Eat (MRE), or fire team leaders may simply give a 

verbal order. Formal written orders take time that many people aren’t willing to give or 

don’t have. Getting everyone to write a formal order in order to visualize the outcome 
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may be a daunting and unattainable task. Nevertheless, for nontrivial operations, clarity 
and accountability are essential. 

5. Document References 

Operation orders are often just the skeleton in larger bodies of information. As 
mentioned before, countless other documents may be referenced in an operation order. 
Other orders, operation overlays, and SOPs often contain core information that is needed 
in order to visualize the plan. Appendix G lists twenty-six (26) different annexes that 
may be referenced. A joint or coalition order can have myriad possible references that 
may be in several languages. In order to capture the information from each of these 
documents, there would have to be a DTD or schema for each one, the DTD or schema 
would have to be updated or changed every time a given document was altered, and the 
XML translation tool would have to be able to parse and differentiate between all the 
possible documents that may have been referenced. For this reason, it may be necessary 
for operation orders to become more verbose in order to cut down on the number of 
referenced documents. This is a shift from the common thinking of brevity versus 
verbosity, but it will prove useful in the long run if clarity is improved. 

F. EXTENSIBLE MARKUP LANGUAGE-MESSAGE TEXT FORMAT 

(XMLMTF) 

The United States Message Text Format (USMTF) has long been the tactical 
messaging tool of choice for the Department of Defense. As the Extensible Markup 
Language (XML) continues to proliferate and gain momentum in the commercial sector, 
many of its proponents have questioned the usefulness of the USMTL system. An XML- 
MTL Development Team was given the task of converting orders from the USMTL 
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format to an XML-MTF format. While work is ongoing, a tool has been developed that 
takes a common USMTF message and converts it into an XML-MTF message. 

1. Public Beta Release 1.02 of MTF2XML Converter 

In July of 2000, UnixPros of Eatontown, New Jersey, released version 1.01 of the 
MTF2XML converter. This tool takes an MTF message input and creates an XML 
message output. It follows the mapping standard set forth in the XML-MTF Mapping 
Public Working Draft that was created by the XML-MTF Development Team in March 
of 2000. It is a Java-based program so it can run on various platforms without having to 
recompile. The tool is only guaranteed to work on Windows NT (other platforms have 
yet to be tested, however, the message in Appendix F was generated using Windows 
2000), and messages should be viewed with Microsoft Internet Explorer 5.0 or higher. 
(Public Beta Release 1.02 of MTF2XML Converter, Readme.TXT file, July 2000) 

G. SUMMARY 

The amphibious invasion scenario for this thesis encompasses a joint exercise 
with coordinated Army, Navy, and Marine Corps participation. While operation orders 
were written for the entire scenario, the focus of this paper is strictly on the amphibious- 
raid and the unit-level orders that correspond to it. 

Operation orders are directives issued by a commander to subordinate 
commanders for the purpose of effecting the coordinated execution of an operation. 

There are guidelines on how to write these orders that are often interpreted in many ways. 
All orders contain a heading, body and ending. The body of the order is the most 
important and is made up of five paragraphs: 1) Situation, 2) Mission, 3) Execution, 4), 
Administration and Logistics, and 5) Command and Signal. Each of these paragraphs are 
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comprised of numerous subparagraphs which contain or make reference to information 
critical to the execution of the mission. The Execution paragraph is of great importance 
as it conveys the Commander’s Intent, Concept of Operations, and the Tasks for the 
mission. 

In writing these exemplar orders, there were two main goals. First, the orders had 
to be joint. Second, the orders had to be realistic. In order to create an order that would 
lend itself to proper tag definitions and provide information necessary for proper 
visualization, an “enhanced” order was created that included timelines and coordinates 
for AAAV movements. While it was possible to alter this exemplar order for purposes of 
research, many limitations on the use of operation orders exist. They are used 
inconsistently across and within the military services, acronyms are used without 
remorse, semantics are not consistent, and countless documents may be referenced from 
which data retrieval must be attempted. Once an order is written and put in the USMTF 
structure, the MTF2XMF Converter takes the MTF input and outputs an XMF message. 
This is a significant first step in attaining a commonly defined message format that is 
interoperable across systems. 
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IV. MODELING AMPHIBIOUS PLANNING AND OPERATIONS 
USING THE NATO LAND COMMAND AND CONTROL 
INLORMATION EXCHANGE MODEL (LC2IEDM) 

A. INTRODUCTION 

Future warfare will increasingly rely on ad hoc coalition environments with 
disparate communication and information technology systems. These systems will need 
to provide functionality and interoperability in order to facilitate the exchange of data 
between Joint US and Coalition international forces. Prior to the start of any operation, 
Coalition partners must review and agree on communications standards to abide by. 
NATO is currently trying to overcome this recurring problem by evaluating a common 
data-interchange specification called the Land C2 Information Exchange Model 
(LC2IEDM). The Naval Undersea Warfare Command (NUWC) and the Institute for 
Defense Analysis (IDA) are working with the Naval Postgraduate School (NPS) to 
extend this primarily land-oriented model to incorporate Naval and maritime 
representations. This chapter briefly introduces the LC2IEDM data model and evaluates 
its suitability for representing amphibious planning and operations. 

A previous version of portions of this chapter was presented in an earlier thesis. 
(Hunsberger, 2001) 

B. DATA INTERCHANGE 

As individuals and groups progress along the “knowledge pyramid” from data to 
knowledge, they work to attain increasingly higher levels of understanding. Systems that 
are interconnected need structured formats for passing information. Structured 
methodologies allow one system to pass specific information to another, with the 
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expectation that the other system can correctly represent it. A command-and-control 


example might be a Marine Corps system passing a structured message ‘Squadron of 
F/A-18s at the air base’ and having an Army system represent the information correctly. 

Data models are used by systems to provide format and message structure. By 
outlining a format and structure, the data model provides the basis for any system to be 
able to send on data that any other system can understand. This information exchange 
model does not specify the way data must be represented or stored on a specific system. 
It only specifies what and how information must be exchanged between different 
systems. This significantly reduces the number of parameters that must be specified and 
gives system implementers freedom to extend the specifications to meet their needs. 

The NATO C3 Technical Architecture (NC3TA) Interoperability Reference 
Model describes four levels for classifying a system’s interoperability. They are: 


Degree 1: Unstructured Data Exchange. Involves the exchange of 
human-interpretable unstructured data such as the free text found in 
operational estimates, analysis and papers. 

Degree 2: Structured Data Exchange. Involves the exchange of human- 
interpretable structured data intended for manual and/or automated 
handling, but requires manual compilation, receipt and/or message 
dispatch. 

Degree 3: Seamless Sharing of Data. Involves the automated sharing of 
data amongst systems based on a common exchange model. 

Degree 4: Seamless Sharing of Information An extension of Degree 3 
to the universal interpretation of information through data processing 
based on cooperating applications. (NC3TA, 2000) 
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The LC2IEDM effectively lays the foundation for Degree 3 Interoperability. 
(NATO, 2000) Designers can further create systems that can seamlessly share data by 
adhering to the model. 

C. GENERIC HUB 

The Land C2 Information Exchange Data Model (LC2IEDM) is formally known 
as the Generic Hub (GH). The name is derived from the understanding that information 
exchange requirements (IERs) will change over time, therefore a flexible generic model 
that can serve as a basis or hub for new systems is needed. NATO’s information 
requirement is to define only information to be exchanged versus modeling all the 
information that might normally be mandatory for a national system. Therefore the intent 
of the GH is to clearly specify the minimum set of data to be exchanged. However, since 
the model is both flexible and generic, nations may compatibly expand their own data 
structures or extend the model to fit their needs. (NATO, 2000) 

The primary goal of the Generic Hub model is to serve as a common information- 
exchange data model. NATO’s automated information-exchange plan requires a 
common specification and a common structure for information to be exchanged. The 
model provides the basis for sharable structured information. It defines standard 
elements of information (e.g. vehicle AAAV, and Location Grid 543789) and can also 
capture relationships between the information (e.g. AAAV is located at Grid 543789). 

“As a minimum, the NATO nations wish to have the GH Data Model preserve the 
meaning and relationships of the information exchanged and thereby attain the 
interoperability associated with NATO Level 5 of System Interconnection (automated 
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exchange of data, with user-imposed constraints, between C2IS databases).” (NATO, 

2000 ) 

Land Combat Operations serve as the common core of the Generic Hub. 
Functional areas are referred to as “subfunctional” areas of the core. These subfunctional 
areas can be viewed as spokes extending from the hub as shown in Figure 4.1. With the 
Generic Hub serving as the basis for the subfunctional area models, data common across 
all the areas is viewed and structured in a standard way. (NATO, 2000) 


Combat Service 
Support & Logistics 


Communications 
and Electronics 


Fire Support 


Air Support 



Administration 
(Personnel) 


Engineer 

Operations 


Air Defense & 
Airspace Control 


Intelligence/Electronic Warfare 
(IEW ) 


Figure 4.1 Hub and Its Relationship to Subfunctional Areas (NATO, 2000) 


D. LAND C2 INFORMATION EXCHANGE DATA MODEL (LC2IEDM) 
DATA SPECIFICATION 

The Land C2 Information Exchange Data Model (LC2IEDM) (formally known as 
the Generic Hub) structure is meant to be generic and include all land, sea and air 
operations. It seeks to define the information that is relevant to the generic battlespace 
and also the information that has meaning within several of the functional areas. The 
model describes objects of interest including forces, equipment, weather, terrain features, 
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and facilities. The data model also includes information about the relationship between 
objects. In order to maintain a common understanding of all content in the model, use of 
free text (i.e. unstructured data) is discouraged. (NATO, 2000) 

The data model has five key and five secondary independent entities. The key 
entities specify information that directly addresses the battlespace and include OBJECT- 
ITEM, OBJECT-TYPE, CAPABILITY, LOCATION, and ACTION. The OBJECT- 
ITEM entity is an individual object that has some military significance. Examples are a 
specific person such as a commanding general or a specific geographic feature such as a 
river. The OBJECT-TYPE entity is an individually identified class of objects with some 
military significance. This might be a type of facility (airfield or mess hall), a type of 
person (rank or position), or a type of feature (fire support area). The CAPABILITY 
entity denotes the ability to perform a mission or function. The LOCATION entity is a 
position within a specific frame of reference. Finally, the ACTION entity is an activity 
or a description of how an activity will take place. Example ACTIONS include operation 
orders, fire missions and logistic requests. 

The five secondary entities include CANDIDATE-TARGET-LIST, CONTEXT, 
REFERENCE, REPORTING-DATA, and RULE-OF-ENGAGEMENT. These entities 
provide information that does not directly address the battlespace. For instance, the 
REPORTING-DATA entity captures metadata from the other entities relevant to 
command and control, and the CONTEXT entity is used to group data from other entities 
without having to create new information. 
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The use of these ten (10) entities, and the relationships between them, allows for 
the full specification of a battlespace situation that can be transmitted between coalition 
systems to convey sharable information. 

E. AMPHIBIOUS MODELING USING LC2IEDM 

It is worth emphasizing that the Generic Hub (GH) is physically nothing more 
than an extensive database governed by a NATO-wide acceptance of common definitions 
for the data that is input. As such, all modeling using the GH is dependent on the entity 
relationships established in the database. The GH alone cannot generate an XML 
document, nor will it unilaterally fabricate a 3D virtual world. The XML schema 
discussed in the next chapter shows how information from the GH can be represented 
using XML, and the stylesheet example shows how to covert one XML document to 
another. 

The following figures demonstrate different levels of entity-relationship diagrams. 
Each entity can be specified to the most discriminating level of detail if desired. This is 
important in that the user defines the preferred level of detail they wish to model. Figure 
4.2 is a very simple diagram showing the relationships between the five key entities. 



Figure 4.2 Key Entities of the Generic Hub Data Model (NATO, 2000) 
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Figure 4.3 expands the level of detail to include most of the secondary entities. 
This is still a very high-level view of the model but it begins to illustrate the added 
complexity and sophistication available. 


OBJECT-TYPE-CAPABILITY-NORM 


CAPABILITY 


OBJECT-ITEM-CAPABILITY 



Figure 4.3 High-level View of the Generic Hub Model (Chaum, 2001) 


Figure 4.4 takes the ACTION entity and breaks it out into an even finer level of 
detail. Figure 4.4 is the foundation for demonstrating how the amphibious-raid scenario 
can be modeled, since it illustrates the relationships between OBJECT-ITEM and 
OBJECT-TYPE to ACTION. The demonstration example provided later focuses on the 
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objective of securing the Camp Pendleton Airfield and utilizes the mapping structure 
illustrated in Figure 4.4. 


ACTION 



Figure 4.4 ACTION, ACTION-RESOURCE, and ACTION-OBJECTIVE Structure 

(NATO, 2000) 


For this example all “battlefield objects” are specified as instances of OBJECT- 

ITEM (Loaiza, 2001). In this case, Alpha Company and the Camp Pendleton Airfield are 
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the OBJECT-ITEMs. Additionally, all activities in the battlefield are represented as 
instances of ACTION (Loaiza, 2001). In the exemplar scenario, Alpha Company was 
tasked with securing the Airfield, so the ACTION is given the value “secure”. The 
NATO agreed-upon definition” in the LC2IEDM specification for “secure is: 


In an operational context, to gain possession of a position of terrain feature, with 
or without force, and to make such disposition as will prevent, as far as possible, 
its destruction or loss by enemy action. (NATO, 2000) 


The other entities are described in the following tables. Each table captures details from 
e-mail correspondence with Francisco Loaiza. 

Table 4.1 expresses the way the WHO-WHAT dyad (who is responsible for what 
action) is represented: 


(a) ACTION 


action-id 

action-category-code 

action-name 

1101 

OP 

Secure 


(b) ACTION-RESOURCE 


action-id action-resource-index 

action-resource-category-code 

1101 

1 

Objectltem 


(c) ACTION-RESOURCE-ITEM 


action-id action-resource-index 

object-item-id 

1101 

1 

11 


(d) OBJECT-ITEM 


object-item-id 

object-item-category-code 

object-item-name 

11 

OR 

Alpha Company 


Table.4.1 ACTION-RESOURCE Example Expressed using Generic Hub Notation, 
derived from (NATO, 2000) ID values are keys representing specific objects or items in 
the given scenario. 
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What Table 4.1 actually says is that the instance of OBJECT-ITEM with id=ll (Alpha 
Company) is the resource for effectuating the instance of ACTION with id= 1101 
(Secure). (Loaiza, 2001) Plainly stated, Alpha Company will secure something. 

Table 4.2 expresses the way the WHAT-TO_WHOM dyad (for what/whom is the 
action intended) is represented. The ACTION table is omitted, as it has not changed 
from Table 4.1: 


(a) ACTION-OBJECTIVE 


action-id action-objective-index 

action-objective-category-code 

1101 

1 

Objectltem 


(b) ACTION-OBJECTIVE-ITEM 


action-item action-objective-index 

object-item-id 

1101 

1 

17 


(c) OBJECT-ITEM 


object-item-id 

object-item-category-code 

object-item-name 

17 

FE 

Camp Pendleton Airfield 


Table 4.2 ACTION-OBJECTIVE Example Expressed using Generic Hub Notation, 

From (NATO, 2000) 

What Table 4.1 communicates is that the instance of OBJECT-ITEM with id=17 (Camp 
Pendleton Airfield), is the recipient of the instance ACTION id= 1101 (Secure). In other 
words, Camp Pendleton Airfield is “secured”. (Loaiza, 2001) 

As expressed in the entity-relationship diagram in Figure 4.4, Tables 4.1 and 4.2 
are not independent of each other. When both “halves” are put together, the model states 
that Alpha Company is the resource that carries out the action “secure” against the 
objective of Camp Pendleton Airfield. 
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It is evident that more data must be recorded and many additional relationships 
developed to complete even the simple amphibious- raid model. One can then surmise 
that the magnitude of complexity for a large-scale joint operation would increase 
exponentially. Nevertheless, once information has been recorded in the database, there is 
no need to re-enter the data again. Moreover, because the data input is defined in terms 
that the US and NATO have agreed on, the information can be shared from one service or 
country to another. 

F. LC2IEDM AND XMIAMTF 

By now it should be apparent that the Generic Hub (GH) and XML-MTF models 
are very complementary. XML-MTF provides a set of tags that capture all of the 
message header and ending administrative information, as well as each section within the 
operation order. While it further breaks the operation order down into Situation, Mission, 
Execution, etc., it typically consolidates all of the content (GENTEXT) into a large, 
unusable single tag. On the other hand, the GH schema (when complete) can provide 
semantic tags that fully capture and structure the content of the operation order. More 
importantly, US and NATO forces have agreed upon these semantic terms, making them 
compatible for coalition use. When used together, each process can leverage off the 
strengths of the other without having to duplicate the effort of creating tags that have 
already been defined. 

G. SUMMARY 

The Land C2 Information Exchange Data Model (LC2IEDM) (formally known as 
the Generic Hub (GH)) increases the effectiveness and efficiency of dissimilar systems 
that require data exchange. The data model supports information interchange by 


standardizing the measures in which the data is exchanged. The model is generic in order 
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to offer the flexibility necessary to permit the creation of a full range of battlespace 
representations over a wide spectrum of military operations. 

The Generic Hub (GH) is an extensive database that depends on the arrangment 
of potentially large sets of entity-relationships to complete a model. The example of 
securing the Camp Pendleton Airfield demonstrated some of the relationships that are 
created between entities. It is up to the author to determine the level of detail desired 
when creating an order or plan. The more data desired, the more complex the structure of 
the model for the order of plan becomes. However, once information has been recorded 
in the database, there is no need to reenter the data again. Also, because the data entered 
is defined in terms that have been agreed upon, the information can be shared from one 
service or country to another. 

Finally, the LC2IEDM and XML-MTF schemas are complementary to one 
another. The XML-MTF tags essentially capture the administrative information and 
message format while the LC2IEDM tags capture the content (GENTEXT) of the 
message. By using the two together, they can leverage each other’s strengths and 
eliminate the need to duplicate the effort of recreating semantic tags that have already 
been defined. 
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V. WEB ACCESS AND XML 


A. INTRODUCTION 

The chapter discusses reasons for using the World Wide Web as a medium to 
distribute and utilize the visualization tool. It also introduces the Extensible Markup 
Language (XML) and the schemas and stylesheet that are being generated for the 
amphibious-raid scenario. It concludes by describing several current efforts that are 
underway within the DoD and commercial sectors that are also committed to the Web 
and XML. 

B. WHY USE A WEB APPROACH? 

The phrase “Web3D content” refers to 3D graphics rendered via a web browser, 
such as a 3D plugin operating inside Microsoft Internet Explorer or Netscape 
Communicator. 3D content needs to be as easy to access and view as 2D text and 
graphics in a Hypertext Markup Langua ge (HTML) document using the browser. This 
distinction is important if scalability, ubiquity, and “ease of use” are to be attained. 
(Blais, 2001) 

3D content must be accessible via networked browsers in order to grow and 
interconnect without bounds. This is different from the separate-program installation 
methodology required by most standalone or large-scale multi-player online games. Lor 
commercial reasons (i.e., billing for services), most large-scale commercial online games 
are separate customized applications that only allow authenticated users to join and 
depart shared virtual environments. In return, such distributed applications provide state 
management and communications among the host servers and other players. The 
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application further provides specialized (usually proprietary) graphics rendering that can 
only utilize 3D content which is uniquely prepared for that application. While this is an 
effective business model for online gaming, it is not a very scalable or robust approach 
for long-term military and scientific applications that must steadily grow and improve 
(and perhaps even interoperate). That is why it is important to use open scalable 
nonproprietary Web-based 3D graphics technologies that are available today. (Blais, 
2001 ) 

C. EXTENSIBLE MARKUP LANGUAGE (XML) 

This section gives an overview of the Extensible Markup Language and further 
discuss specific aspects of the language that impact the research of this thesis. 

1. Overview 

The Extensible Markup Language (XML) was designed to provide the simplicity 
of the Hypertext Markup Language (HTML) and the information exchange benefits of 
the Standard Generalized Markup Language (SGML). It became a World Wide Web 
Consortium (W3C) specification in Lebruary 1998. XML was created to enable richly 
structured documents to be employed on the Web; in other words, it is a markup language 
for documents containing structured data. Two major benefits of XML are that it is free 
and platform independent. 

With HTML, tag semantics and tag sets are fixed. XML does not specify 
semantics or tags. Therefore, XML semantics and tags are user defined. The examples 
in Ligure 5.1 demonstrate how HTML describes the format of a document whereas XML 
describes the structure and semantics. It is clear that the XML tag has been defined in a 
manner that is descriptive and human readable. The tag describes the data encapsulated 
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within it. The product of data describing data is referred to as metadata. This is an 


extremely powerful and valuable function of XML. The <p> tag pair in the HTML 
document denotes a paragraph. This construct is primarily for presentation purposes and 
does not provide any useful semantic information. One note of concern worth 
mentioning is that because XML tags are user-defined, there are many equally valid ways 
to express the same data using different terms and structures. The uncoordinated addition 
of tagsets will reduce data interoperability rather than improve it. (Crawford, 2001) 


A. HTML EXAMPLE 

<html> 

<head> 

<title>Department Heads</title> 

</head> 

<body> 

<p>C0: Col Stargazer</p> 

<p>X0: LtCol Imnext</p> 

<p>S-l: CW03 Lostit</p> 

<p>S-2 : Capt Knowit</p> 

<p>S-3: Capt Writingit</p> 

<p>S-4 : Maj Outofit</p> 

<p>S-6: Maj Rebootit</p> 

</body> 

</html> 

B. XML EXAMPLE 

<R0STER> 

<TITLE>Department Heads</TITLE> 

<COMMANDING_OFFICER>CO : Col Stargazer< /COMMANDING_OFFICER> 
<EXECUTIVE_OFFICER>XO : LtCol Imnext</EXECUTIVE_OFFICER> 
<ADMINISTRATION_OFFICER>S-l : CW03 Lostit</ADMINISTRATION_OFFICER> 
<INTELLIGENCE_0FFICER>S-2 : Capt Knowit</ INTELLIGENCE_OFFICER> 
<TRAINING_OFFICER>S-3 : Capt Writ ingit</TRAINING_OFFICER> 
<SUPPLY_OFFICER>S-4 : Maj Outof it</SUPPLY_OFFICER> 

<COMMUNICATIONS_OFFICER>S-6 : Maj Rebootit</COMMUNICATIONS_OFFICER> 
</ROSTER> 


Figure 5.1 A. HTML Example for Presentation B. Corresponding XML Example for 

Content Semantics 
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2. XML Components 

While there are many components and rules for creating a proper XML document, 
only those that have a direct effect on this thesis are discussed. There are countless 
numbers of XMLbooks, Web pages, magazines, presentations and other resources 
available for readers who desire more information on the subject. A good starting point 
is the World Wide Web Consortium (W3C) home page at http://www.w3.org. 

a. Elements and Attributes 

Elements and attributes are the fundamental nodes used to create XML 
documents. Elements consist of a start and end tag, and are characteristically given 
descriptive names to denote meaning. In Figure 5.1, <supply_officer>s- 4 : Maj 
Out of it </ supply_officer> is the element <SUPPLY_OFFICER> containing the data 
“S-4: Maj Oulofit”. Tag names must begin with a letter, underscore or colon. Follow on 
characters can be letters, numbers, etc., but cannot contain whitespace. As noted earlier, 
it is easy to depict the same data using different tag names. Because XML parsers are 
case sensitive, the element <SUPPLY_OFFICER> is not the same as <Supply_Officer> 
or <supply_officer>, but (to humans at least) all three versions clearly describe the same 
data. 

Attributes enable an author to define extra information about an element. 
Values given to attributes are strings that must be delimited by quotation marks. An 
example of an attribute is <Service branch=”USMC”> where <Ser\’ice> is the element 
with the attribute branch having the value “ USMC ”. There are arguments for and against 
the use of attributes. Arguments against include the inability of attributes to specify 
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structure, and their tendency to inhibit document readability when they are used in 
excess. Arguments for include attributes usefulness in describing the unique properties 
of an object and therefore increase the metadata provided. In any case, a good rule of 
thumb is to use an attribute for simple, unstructured “secondary” information that is 
unique and cannot be separated from the concept of the element. 

b. XML Schema 

An XML Schema formally specifies a coherent set of definitions for 
elements and attributes. Within the schema definition are declarations of which elements, 
attributes etc. are legal within a document, and also the locations where they are legal. 
(Goldfarb, 2001) In other words, the schema specifies the content and structure of an 
XML document. If a document does not conform to the XML specification it is not 
valid. 


The XML Schema is a W3C recommendation that was created to improve 
deficiencies of the Document Type Definition (DTD). DTDs also specify the content and 
structure of an XML document, but DTD document schemas are not written in XML and 
only support character data. XML schemas make up for these deficiencies while 
providing other new capabilities that make it more robust and powerful than a DTD. 

Some of the extensive additional capabilities that schemas provide include: 

• New built-in data types such as integers and dates; 

• User-defined data types can be created to put additional constraints on 
built-in data types; 

• Any non-negative whole number can be used to specify the number of 
child element occurrences (formerly just zero, one, and infinity were 
allowed) 

• Schema constructs can be imported from existing schemas, and; 
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• A process called refinement enables elements to inherit content and 
attributes from other elements. (Bird, 1999) 

c. Extensible Stylesheet Language (XSL) 

The Extensible Stylesheet Language (XSL) is a W3C specification for 
applying standard formatting to XML documents. It is made up of two standards: format 
and transformation. The formatting standard defines the semantics of formatting in the 
form of a catalog of formatting objects. The transformation standard has evolved into a 
language that is autonomously useful for transforming one XML document to another. It 
is known as Extensible Stylesheet Language for Transformations (XSLT). XSL is the 
link between abstract data required for computer processing and the formatted rendition 
essential for human readability. XSLT transforms a document from an abstraction to a 
rendition. (Goldfarb, 2001) By using multiple XSL stylesheets, a single message can be 
formatted for text, HTML, printing, or e-mail. 

D. XML SCHEMAS FOR THE AMPHIBIOUS-RAID 

As discussed before, the XML-MTF operation order is insufficient in the way it 
handles the GENTEXT information. In order to filter out the essential data from the 
TASK sections, it is necessary to create and define another set of XML tags. 

Lurthermore, these tags need to be compliant with the Generic Hub (GH) in order to 
benefit from the coalition database. The XML schema in Appendix I defines the critical 
information that is needed for proper 3D visualization of the order. It leverages all of the 
tags from the XML-MTL DTD that give the order it’s structure, but it contains additional 
elements and attributes specifically designed to capture the data from the TASKS section 
of the order. An ORGANIZATION element was created to represent the MEU, BLT, 
Company and Platoon. This element is given the attribute NAME to allow each 
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ORGANIZTION element to be described as 15 th MEU or Alpha Company. Each 
ORGANIZATION element may be nested in another element to form a hierarchical 
“parent-child” structure. This enables Alpha Company to be an element of the BLT, or 
1 st Platoon to be an element of Alpha Company. Other elements were added to define 
tags in the TIMELINE AND MOVEMENT section of the order. These elements map to 
the data added to the USMTF “Enhanced” Order in Appendix E. In other words, 
elements were created for INSERTION, INFILTRATION, WAYPOINT, etc. To account 
for movement times, an attribute group named START TIME was created with attributes 
that comprise a date time group (DTG). Another attribute group named LOCATION 
was created to facilitate defining locations. Attributes in this group include LAT/LONG 
coordinates, GH associated id numbers (used to establish entity relationships as discussed 
in the previous chapter), and Names. While the schema is still a “work in progress”, it is 
practically acceptable in its present state. Appendix J is an XML operation order that has 
been generated using the new schema. This order sho uld be compared with the order in 
Appendix F to get a full appreciation of what the XML schema can do. 

In order for the operation order in Appendix J to interoperate with the Generic 
Hub, another XML schema defines semantic tags that attempt to embrace all possible 
elements incorporated in the database. This schema is robust in that it works for any 
document or order that may utilize the element tags, not just operation orders. Segments 
of this schema is located in Appendix K. Appendix L contains parts of a GH compliant 
operation order that follows the rules of the GH schema. This order is what the order in 
Appendix J must transform into to be compliant with the database. An XSL stylesheet 
(discussed in the next section) is needed to make that happen. Once the order is 
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amenable to the GH schema, data is entered into the database by means of a Visual Basic 
script. 

E. XMGMTF TO GENERIC HUB USING XSU 

In order for the operation order in Appendix J to become the operation order in 
Appendix L, and thereby compliant with the GH, an XSL stylesheet is applied to change 
its format. Specifically, XSLT is used to transform one XML document into another. 
Once this link is complete, an extremely important chain reaction can occur. Operation 
orders can be produced with the improved XML-MTF schema, transformed into orders 
compliant with the GH schema and read into the database. However, this is not a “one¬ 
way” feed. Once autogeneration of the 3D scene is functional, the GH database will be 
able to feed and update the information in the scene; in other words the data flow and 
transformation works both ways. This concept is made clearer in Appendix H. 

F. RELATED EFFORTS 
1. Semantic Web 

The Semantic Web strives to make the Web useful not only for communication 
between humans, but also to allow machines to participate and help. Its goal is to allow 
robots and other automated tools to interpret information on the Web. (Semantic Web 
Activity Statement, 2001) “The Semantic Web will bring structure to the meaningful 
content of Web pages, creating an environment where software agents roaming from 
page to page can readily carry out sophisticated tasks for users.” It is not a separate Web 
but rather an extension of the current one. (Berners-Lee, May 2001) 

The Semantic Web will leverage two existing technologies and add a third 

component to round out its development. The existing technologies are XML and the 

Resource Description Framework (RDF). The RDF is an application of XML and is used 
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to put data into the Web in a form that can be processed by machines using a common 
data model and data schemas that can be interpreted by machines. (Semantic Web 
Activity Statement, 2001) The final component is an ontology, which is a document or 
file that formally defines the relations among terms. Software agents using this 
component will be able to discover common meanings for terms across multiple 
databases. (Berners-Lee, 2001) 

2. Task Force Web (TFW) 

Task Force Web is an initiative sponsored by the Department of the Navy Chief 
Information Officer (DON CIO). It seeks to Web-enable the Navy’s applications, and 
uses XML as a key element in its architecture. Building on current Navy-Marine Corps 
Internet (NMCI) and IT-21 infrastructures, TFW is to have at least 50 applications Web- 
ready by 1 November 2001, and all applications ready by 2004. (TFW, 2001). X3D, 
XML-based Generic Hub and XML-MTF are all excellent candidates to become TFW 
exemplar systems. 

3. Geography Markup Language (GML) 

The Geography Markup Language is an XML-based language for encoding 
geographic information. It is intended to enable the transport and storage of geographic 
information to include properties and geometry of geographic features. A product of the 
Open Geographic Information Systems (OpenGIS) Consortium, GML should make an 
impact on the ability of organizations to share geographic information with one another, 
and to enable linked geographic datasets. GML is intended to describe the geography of 
entities in the real world, not the visualization of geographic features. As such, GML 
looks to transform its XML encoded features into XML encoded graphics elements such 


as VRML. (Johnson, 1999) 
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G. SUMMARY 

3D content must be accessible via networked browsers in order to grow and 
interconnect without bound. 3D content needs to be as easy to access and view as 2D 
text and graphics in a Hypertext Markup Language (HTML) document using a browser in 
order to attain scalability, ubiquity, and “ease of use”. 

The Extensible Markup Language (XML) was created to enable richly structured 
documents to be employed on the Web. It was designed to provide the simplicity of the 
Hypertext Markup Language (HTML) and the information exchange benefits of the 
Standard Generalized Markup Language (SGML). As a World Wide Web Consortium 
(W3C) specification, XML is a free and platform independent language. It allows users 
to define their own tags, and therefore their own metadata (i.e. data describing data) that 
makes the original structured information more useful and readable to humans. 

The XML schemas and stylesheet for the amphibious-raid are presented in this 
chapter. One schema extends the XML-MTF DTD by defining elements that extract data 
from the GENTEXT portions of the operation order. The other schema defines possible 
elements incorporated in the GH database. The stylesheet transforms one XML 
document to another XML document that is compliant with the GH database. Generally 
speaking, an XML schema is a catalog of definitions for elements and attributes. The 
schema specifies the content and structure of an XML document. The Extensible 
Stylesheet Language (XSL) is utilized for applying standard formatting to XML 
documents. By using multiple XSL stylesheets, a single message can be formatted for 
plain text, HTML, printing or e-mail. 
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There are numerous efforts within the Department of Defense and in the 
commercial sector that are simultaneously leveraging the benefits of XML and the Web. 
The Semantic Web, Task Force Web, and the Geography Markup Language are just a 
few examples. As XML progresses and XML tools become more robust, it is clear that 
XML will become essential for most information systems. 
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VI. 3D GRAPHICS AND VISUALIZATION 


A. INTRODUCTION 

This chapter describes concepts that are fundamental for understanding how 
complex three-dimensional (3D) worlds are created. It discusses the Virtual Reality 
Modeling Language (VRML), DIS-Java-VRML and Extensible 3D (X3D). 

B. 3D MODELING AND VISUALIZATION TECHNIQUES 
1. Virtual Reality Modeling Language (VRML) 

The Virtual Reality Modeling Language (VRML) is a Web-based graphics 

language for building 3D models. VRML allows user interaction within a scene through 
viewpoint, movement, and rotation. One of the key features of VRML is it is an ISO 
standard designed for use over the World Wide Web. 

VRML worlds are created using a scene-graph structure. Scene graphs are simply 
a hierarchical decomposition of components that will be rendered in a scene. Scene 
graphs are comprised of various groups of nodes, which together form a virtual world. 
These nodes are responsible for displaying shapes, interaction, and movement through 
the world. VRML worlds can be viewed with any VRML-capable browser such as 
Cosmo Player or Cortona, which can be downloaded at no cost from the internet and 
support both Internet Explorer and Netscape as plug-ins. 

There are numerous examples of 3D images and objects available on the Web. 
These examples demonstrate how groups of nodes are used to create complex 3D objects 
and virtual worlds. The following list is an excellent reference for 3D examples: 

o Naval Postgraduate School VRML Course examples are available at 
http://www.web3D.org/TaskGroups/x3d/translation/examples/toc.html 
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o VRML Sourcebook examples at 

http://www.web3D.org/TaskGroups/x3d/translation/examples/Vrml2.0Sou 

rcebook/toc.html 

o VRML/X3D Conformance examples at 

http://www.web3D.org/TaskGroups/x3d/translation/examples/Conforman 

ce/toc.html 

o Scenario Authoring and Visualization for Advanced Graphical 

Environments (Savage) project at 

http: //web .nps. navy .mil/~brutzman/S avage/toc. html 

a. Visual Nodes 

Visual nodes are the foundation for generating 3D virtual worlds. The 
Shape node is the node in which the form and appearance of a 3D object are defined. 

The Shape node consists of four primitive shapes: Box, Cylinder, Cone, Sphere. Each 
shape can be manipulated by changing field values such as the radius of a sphere or the 
height and width of a box. In addition to manipulating the shapes, each shape has an 
Appearance node in which material and texture fields can be changed. The 
Material node allows the user to choose colors, shininess, transparency, and how 
bright or dull the color will be. The Texture node allows the user to apply a 2D texture 
(such as brick or water) to a 3D object to increase realism. In addition to changing the 
appearance and texture of a shape, other nodes are available that allow the user to 
translate, rotate, size, and orient the shape within the scene graph. 

Shape nodes are not limited to the primitive geometries mentioned above. 
Advanced geometries exist that allow the user to create more complex objects and closely 
approximate smooth surfaces and terrain. These nodes include (but are not limited to) 
IndexedFaceSet, Extrusion, and Elevation Grid. Figures 6.1 and 6.2 
demonstrate how complex objects can be built using a variety of visual nodes. 
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Figure 6.1 Landing Craft Air Cushioned (LCAC) Exiting the Well Deck of a San 

Antonio Class LPD-17 



Figure 6.2 AH-1Z Super Cobra Patrolling “Red Beach” at Camp Pendleton 
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b. Grouping Nodes 

Grouping nodes are used to band other nodes into a common entity, and 
then treat and manipulate that entity as a whole. The Group node is the most basic of 
these nodes, and simply serves as a container for children nodes. More powerful is the 
Transform node, which allows a builder to manipulate an entity’s size, position, and 
orientation within its own coordinate system. This node allows large parts of a virtual 
world to be manipulated at one time. 

c. Viewing Nodes 

Viewing nodes are used to set up predefined “camera” viewpoints within a 
virtual world. A Viewpoint node is used to predefine a position and orientation that 
automatically takes a viewer to that location when first entering the world. Additional 
viewpoints can be defined that enable the viewer to easily navigate to predetermined 
areas throughout the world. These viewpoints can be selected randomly from a simple 
Graphical User Interface (GUI) list, or visited in order by simply using the Page Down 
key on the keyboard. Viewpoints are very important when trying to navigate through 
large, complex virtual worlds. Predetermined viewpoints do not, however, disable a 
viewers ability to self navigate through a virtual world. Another viewing node is the 
Navigationlnfo node. This node determines how a viewer navigates through a 
world. This node can be set to let a user walk, fly, or examine the world around them. 

d. Animation Nodes 

Once a 3D world is populated with objects, it is usually desirable to make 

it come alive. In order to animate an object in a 3D world, VRML needs a clock, 

interpolator and a route. A clock can be created using the Time Sensor node which 

provides features for starting, stopping and controlling how quickly the animation plays. 
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The Posit ionlnterpolator and Orientationlnterpolator nodes describe 
the changes that occur during an animation. Using a technique called keyframe 
animation, a position or rotation is specified for only a few, key fractional times. The 
VRML interpolator nodes use these key fractional times and values as a rough sketch of 
the animation and fill in the values between those specified as needed. As the animation 
progresses, new positions and orientations are selected and output. (Ames, 1997) 

In order to make animations work, a circuit must be created between 
nodes to exchange the information that will ultimately make things move. In order to do 
this, VRML uses ROUTE descriptions. A ROUTE can take an output from a 
TimeSensor node and “wire” it into an input field of an interpolator node. Another 
ROUTE is used to “wire” the interpolator node’s output into an input field of a 
Transform node. Once the circuit is complete, the TimeSensor node’s clock can be 
started. Events flow from the TimeSensor node to the interpolator, and from there to 
the Transform node, causing the node’s coordinate system to translate, rotate, and 
scale as the animation plays back. (Ames, 1997) 

e. Sensor Nodes 

Sensors are the primary means of providing interaction in a virtual world. 
VRML sensors are activated when a cursor, mouse arrow, or other pointing device is 
moved over or clicked on an object. When the viewer clicks on an object with an 
attached sensor, the sensor outputs events that can be routed into other nodes to start 
animations (Ames, 1997). The main sensor nodes are: TouchSensor, 
PlaneSensor, SphereSensor, and CylinderSensor. The nodes all act 
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similarly, but the latter three provide the additional capability of selectively moving 
objects within the world. 

/. Script Node 

The Script node is used when native VRML animation features are 
insufficient. This node is used to integrate programs using Java or JavaScript 
(EcmaScript), and can be very powerful in creating more complex animations or 
calculations in the scene graph. 

g. PROTO and EXTERNPROTO Definitions 

A PROTO (prototype) and EXTERNPROTO (external prototype) are used 
to create and define a new node type. A PROTO is usually a combination of many other 
nodes that have been grouped together to make a complex object that may be useful or 
necessary to reuse. For instance, a helicopter may be defined as a PROTO so as not to 
have to recreate it to be used at a later time. As complex PROTOS become common, it is 
useful to maintain them in your own external library. An EXTERNPROTO declaration is 
a reduced version of a PROTO. The EXTERNPROTO specifies a URL that points to an 
external file containing the PROTO (Ames, 1997). This provides for efficient network 
storage, accessibility and reuse. The corresponding X3D nomenclature for these 
constructs is Prot oDeclare, ExternprotoDeclare and Protoinstance. 

2. GeoVRML 

GeoVRML 1.0 is an extension of the Virtual Reality Modeling Language 
(VRML) that allows for accurate rendering of geographic data. While this thesis does not 
make use of GeoVRML in its current state, it is important to discuss as it has tremendous 
utility for follow-on work. 
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Geo VRML 1.0 is a “Recommended Practice” of the Web3D Consortium. It is 


open source and freely downloadable to the public at www.geovrml.org. Geo VRML 1.0 
provides a suite of solutions for representing and visualizing geographic data. It provides 
the following list of high-level capabilities: 

1. Coordinate Systems - Geo VRML provides the ability to embed 
latitude/longitude or UTM coordinates directly into a VRML file and have the 
browser transparently fuse these into a global context for visualization. 
GeoVRML 1.0 supports 3 coordinate systems, 21 ellipsoids, and 1 geoid. 

2. Precision - VRML97 provides only single-precision floating point values. 
This is insufficient to represent data on a planetary scale down to around 10 m 
resolution or beyond. GeoVRML provides solutions to extend this precision 
and enable sub-millimeter positional accuracies. 

3. Scalability - GeoVRML provides various scalability features to manage the 
streaming of large, multi-resolution models over the Web. 

4. Metadata - GeoVRML provides the ability to specify a generic subset of 
metadata describing geographic objects, including the ability to link to a full 
metadata description. 

5. Animation- The ability to interpolate within the supported geographic 
coordinate systems is provided so that animations can be defined with respect 
to key points on the surface of the planet. 

6. Introspection- Functionality is provided to be able to query a GeoVRML 
scene and discover the geographic coordinate of any georeferenced point. 

7. Navigation- GeoVRML 1.0 provides some basic support for navigation 
schemes that are specific to geographic applications. Specifically, the issue of 
elevation scaled velocity is addressed. 

GeoVrml 1.0 is a suite of ten nodes designed to enhance virtual worlds by making 
them geographically accurate. Table 6.1 is an overview of the nodes. Following the 
table are more complete definitions for nodes that have significant military application. 
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Node Name 

Description 

GeoCoordinate 

Build geometry using geographic coordinates 

GeoElevationGrid 

Define a height field using geographic coordinates 

Geolnline 

Inline a file with control over when to load and unload the data 

GeoLocation 

Georeference a vanilla VRML model onto the surface of the earth 

GeoLOD 

Level of detail management for multi-resolution terrains 

GeoMetadata 

Include a generic subset of metadata about the geographic data 

GeoOrigin 

Specify a local coordinate system for increased precision 

GcoPos it ion Interpolator 

Animate objects within a geographic coordinate system 

GeoTouchSensor 

Return the geographic coordinate of the object being pointer to 

Geo Viewpoint 

Specify viewpoints using geographic coordinates 


Table 6.1. Nodes Covered by GeoVRML 1.0 Recommended Practice. 

(Iverson, 2000) 


a. GeoElevationGrid 

The GeoElevationGrid node lets users specify a grid of elevations 
within a geographic coordinate system. These are then transparently transformed into a 
geocentric, curved-earth representation. A height field can be created by simply 
specifying all coordinates in terms of latitude, longitude, and elevation. (Iverson, 2000) 
This allows for 3D visualization of fingers, draws, mountains, cliffs, and other heightened 
terrain important for the military planner. It would help in mapping routes, possible 
enemy strongpoints, and helicopter landing zones to name a few. 

b. GeoLocation 

The GeoLocation node provides the ability to georeference any 
standard VRML model. That is, to take an ordinary VRML model and specify its 
absolute location on the surface of the earth. (Iverson, 2000) This would allow military 
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planners the ability to place ships, landing craft, tanks, squads, artillery and other assets at 
precise locations in the virtual battlespace. 

c. Geo Origin 

The GeoOrigin node defines an absolute geographic location and an 
implicit local coordinate frame against which geometry is referenced. This node is used 
to translate from geographical coordinates into a local Cartesian coordinate system that 
can be managed by a VRML browser. (Iverson, 2000) 

d. GeoPositionlnterpolator 

The GeoPositionlnterpolator node provides an interpolator 
capability where key values are specified in geographic coordinates and the interpolation 
is performed within the specified coordinate system. (Iverson, 2000) The 
GeoPositionlnterpolator works much like the Positionlnterpolator 
node in VRML. Animation is achieved by routing TimeSensor information to the 
GeoPositionlnterpolator, and from the interpolator to the GeoLocat ion 
node. For example, an AAAV can be moved from its initial location across the water and 
onto a beach landing site, stopping and starting as necessary based on TimeSensor 
inputs. Using this combination of nodes on many ships, landing craft, aircraft, and 
personnel would give the planners the ability to watch an entire amphibious operation 
unfold in 3D. 

e. GeoViewpoint 

The GeoViewpoint node allows users to specify a viewpoint in terms 
of a geographic coordinate. This node can be used wherever a standard Viewpoint node 
can be used. A GeoViewpoint and Viewpoint node can be combined in the same file. 
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(Iverson, 2000) The GeoViewpoint is very valuable in that it allows the user to easily 
navigate through vast complex virtual worlds. Because the viewpoint is in terms of a 
geographic coordinate, planners can choose viewpoints that will help them see the virtual 
battlefield from specific locations on key pieces of terrain. For example, if consideration 
is being given to move troops up a draw, a viewpoint could be set at the crest of a finger 
looking down into the draw in order to get an enemy perspective. The outcome may be 
to change courses of action or plan a new route. This is invaluable for land and air assets 
alike. 


3. DIS-Java-VRML 

The Institute of Electrical and Electronic Engineers (IEEE) Distributed 
Interactive Simulation (DIS) Protocol is used to communicate state 
information (such as position, orientation, velocities and accelerations) 
among entities participating in a shared network environment. Java is a 
portable networked programming language that can interoperate on any 
computer that includes a Web-browser. The Virtual Reality Modeling 
Language (VRML) enables platform- independent interactive three- 
dimensional (3D) graphics across the Internet, and can be used to compose 
sophisticated 3D virtual environments. (Brutzman, 2001) 

The DIS-Java-VRML Working Group is developing a free open-source software 
library that allows DIS and VRML to interoperate by implementing Java code. Its goal is 
to provide libraries and examples that allow scene developers to build networked 3D 
worlds that are portable, pervasive, scalable and viewable on any computer with a 
browser and network connection. (Brutzman, 2001) 

C. EXTENSIBLE 3D (X3D) 

The next-generation specification for VRML is the Extensible 3D (X3D) standard 
(Brutzman, 2001). X3D is a scene graph and text-based encoding designed to overcome 
several limitations of the VRML standard. X3D includes an Extensible Markup Language 
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(XML) encoding to express identical VRML geometry and behavior structures. X3D is 
thus a standardized XML tagset for describing the VRML 200x standard for Web- 
compatible 3D content. Such content is not static but dynamic, driven by a rich set of 
interpolators, sensor nodes, scripts, and behaviors. (Blais, 2001) 

X3D/VRML 200x is capable of compatibly using all legacy VRML 97 content. 
X3D provides new interoperability with other relevant standards including MPEG-4 and 
an entire family of XML-based languages. X3D further addresses several shortcomings 
of VRML 97, provides tighter media integration, improved visual quality through 
advanced-rendering nodes, and enables a component-based approach. (Blais, 2001) 

Using the X3D-Edit authoring tool, developers can create valid scene graphs with 
little trouble. The tool is simple enough that even novice 3D developers can create 
virtual worlds with relative ease. When generating a scene, the X3D-Edit software limits 
the developer to only see allowable choices. Only valid nodes can be selected, 
eliminating guesswork and potential errors. X3D-Edit utilizes IBM’s Xeena XML editor 
configured to work with the X3D document type definition (DTD). Documents are 
translated into VRML using the Extensible Stylesheet Language (XSL), and a browser is 
automatically launched for convenient debugging. (Brutzman, 2001) Figure 6.3 shows a 
screen shot of the X3D Edit tool. 
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Figure 6.3 Screen Capture of the X3D Edit Tool 


D. SUMMARY 

The Virtual Reality Modeling Language (VRML) is a Web-based graphics 
language for building 3D models. VRML allows user interaction within a scene through 
viewpoint, movement, and rotation. VRML worlds are created using scene graphs that 
are comprised of various groups of nodes. These nodes are responsible for displaying 
shapes, interaction, and movement through the virtual world. Geo VRML 1.0 is an 
extension of VRML that allows for accurate rendering of geographic data. While not 
used in this thesis, it will be extremely useful to military planners and should be followed 
closely as it becomes more robust. Extensible 3D (X3D) is the next-generation 
specification for VRML. It was designed to overcome some of the limitations of the 
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original VRML specification and incorporates the use of the Extensible Markup 
Language (XML). These technologies provide a scalable Web-based approach to 
networked 3D graphics that is suitable for generation and distribution of large-scale 
virtual environments. 
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YD. EXPERIMENTAL RESULTS 


A. INTRODUCTION 

This chapter describes how the concept of how to represent and visualize the 
amphibious-raid scenario is implemented and demonstrated. It concludes with a number 
of different yet equivalent methods for describing and presenting such tactical scenarios. 

B. SCENARIO AUTHORING 

1. Motivation 

The Director of Training and Education Command at the Marine Corps Combat 
Development Command (MCCDC) in Quantico, Virginia wanted to develop a tool that 
could “bring the basic concepts of amphibious operations to the masses”. Believing in 
the power a tool like this could deliver to the Marine Corps, and having recently been 
exposed to VRML and, to a lesser degree, XML, it was clear that the foundation for 
creating this tool was already available. Armed with the knowledge that this could be 
done, it was decided that an amphibious-raid scenario of limited complexity was an 
excellent starting point to begin modeling some of the “basics of amphibious operations.” 

2. Methodology 

In order to author and visualize an amphibious-raid, it was decided that a 
filmmaker approach would be taken. Drawing on prior experience and using the 
Amphibious Warfare School Non-resident Program Expeditionary Operations Course as 
a resource, a realistic and tactically correct scenario was outlined. Lrom the outline, 
storyboards were drawn to correspond to the “scenes” that were needed to convey an 
accurate and believable visualization of the scenario. 
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Having storyboarded the entire scenario, a trip was made to “Red Beach” at Camp 
Pendleton, California to observe an amphibious capabilities exercise (CAPEX). This was 
an invaluable visit because it provided the opportunity to take photographs of the terrain, 
aircraft, landing craft, and ships that needed to develop into 3D models for the scenario. 
Furthermore, the luxury of observing a live-action operation enabled the storyboard 
vision to be refined and take on a new life of its own. 

While 3D models were being generated, each storyboard was coupled with an 
actual photo that was consistent with the “theme” it conveyed. The next step was 
providing a text description for each storyboard/photo pair that put into words what was 
actually happening in each scene. This permitted scenes to have deeper meaning given 
that each set of pictures was complemented with background and tactical information. 

As models became available, the visualization of the amphibious-raid started to 
take shape. Lacking an adequate XML DTD or schema that allowed for the conversion 
of operation orders into automatically generated 3D worlds, a scripted version of the raid 
was created (see Appendix N). For each text description/storyboard/photo set, an 
analogous screen capture was added from the virtual raid. This added a new level of 
depth in visualizing how everything fit together. 

Lastly, the operation orders were written as discussed previously in Chapter III. 
The amphibious-raid and corresponding unit-level orders were focused on because 
modeling and translating orders for the entire joint scenario would have been attempting 
too much too soon. Once written, the order added yet another level of depth in seeing 
how everything tied together. 
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3. Tactical Assumptions for the Amphibious Raid Scenario 

In order to keep the scenario realistic, yet simple enough to model, some 
assumptions had to be made. These tactical assumptions are not meant to be realistic in 
all cases, but are sensible limitations for a generic example without loss of generality. 

The amphibious-raid takes place during twilight hours on a calm sea (sea-state is 
0-1 (flat)) where the wind is less than 10 knots. Helicopters have been conducting 
routine patrols for a number of days prior to the raid. Since the enemy is used to hearing 
the helicopters, there is no suspicion when they are heard while actually providing cover 
noise for the raid. The raid is on a hostile beach, but is generally clear of enemy troops or 
fortifications. This allows for the entire raid force to land in one wave. 

The next few ideas are notional, but important in understanding some of the 
decisions made for the scenario. Developmental systems such as the San Antonio class 
LPD-17 and the AAAV are assumed to have been fielded and fully employed. An ATO 
has already been written for the Super Cobras- a new ATO was not written for this 
scenario because the Quigley/Murray thesis handled this subject sufficiently and there 
was no need to repeat their work. Finally, each AAAV holds a reinforced Marine 
platoon. 

4. Tactical Limitations 

In order to keep the virtual raid as simple as possible, a number of limitations 
were placed on the scenario: 1) The amount of vehicles were kept to a minimum and 
don’t fundamentally reflect a realistic battlefield picture (more AAAVs would have to be 
added to truly carry a reinforced company of Marines from ship-to-shore), 2) There is no 
enemy contact or enemy obstacles while in transit to, or while crossing the beach landing 
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site (BLS), 3) There are no avatars representing individual Marines, rather they are 
considered to be represented by the AAAV. 


In order to keep coding simple while manually scripting the scene, the AAAVs 
were made to move as one entity instead of individually (movement at the airfield is the 
only exception). Because they are bound together, individual movements 1100m and 
500m from the BLS are precluded. Instead, the AAAVs go directly from ship to shore. 
C. EXEMPLAR TACTICAL SCENARIO 

This section gives visual insight into the methodology described earlier. It 
demonstrates how the text description, storyboard, photo, and 3D screen shot all work in 
parallel to describe the exact same scene. Operation orders are not included here, as they 


have been discussed at length throughout this thesis. 


1. Scene 10: Beach Landing Site (BLS) 


Location 

• Red Beach, Camp Pendleton California 
Description 

• Beach landing site on a hostile shore 

• Morning hours of twilight 
Purpose 


• Establish initial viewpoint from objective 
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2. Scene 20: Helicopter Sortie 

Location 


• Flight deck of the LPD-17 
Description 

• AH- 1Z Super Cobra helicopters prepare for takeoff 
Purpose 

• Provide cover noise for the incoming raid force 



Storyboard 


Photo 


3D Screen Shot 


3. Scene 30: AAA Vs Exit LPD Well Deck 


Location 

• Insertion point from well deck of San Antonio class LPD -17 
Description 

• Three AAAVs get underway 


Purpose 


• Each AAAV has one squad of Marines 

• Squads: command, recon/security and covering elements 

• These squads comprise the raid force 



Storyboard 


Photo 


3D Screen Shot 
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4. Scene 40: Helicopters on Patrol 

Location 

• Flying over the Pacific Ocean and Red Beach 
Description 

• AH-1Z Super Cobra helicopters fly a regularly scheduled reconnaissance 
route 

Purpose 

• Provide cover noise for the incoming raid force 

Seems 40: 

HftMcopton on Petrol 


Storyboard Photo 3D Screen Shot 

5 . Scene 50: AAAVs 1100m from Beach Landing Site 

Location 

• Control point 1100m from beach landing site 
Description 

• Raid force moves from a wedge to an on hne formation 
Purpose 

• Ensure everything is still a “go” before raid force proceeds 
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6. Scene 60: Recon Element Advances 


Location 

• Control point 1100m from beach landing site 
Description 

• Recon/security AAAV travels to the Line of Departure (500 m from the beach 
landing site) 

Purpose 

• Insert scout swimmers for reconnaissance of surf and beach 

• Command and covering elements wait at their current location 



7. Scene 70: Scout-Swimmers 


Location 

• Line of Departure 500m from the beach landing site 
Description 

• Team of six to eight scout-swimmers from the recon/security element 
enter the water 

Purpose 

• Ensure that beach landing site and water approaches are clear of hazards 



Storyboard 


Photo 
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3D Screen Shot 











































8. Scene 80: Recon Complete 

Location 


• Line of Departure 500m from the beach landing site 
Description 

• Scout-swimmers signal the raid force to land using a green directional 
chemlight (only visible to the raid force still at sea) 

Purpose 

• This is the planned signal that recon is complete and it is OK to land 





9. Scene 90: Raid Force Regroups at Line of Departure 

Location 

• Line of Departure (LOD) 500m from the beach landing site 
Description 

• Command and covering elements join the recon/security element at LOD 
Purpose 

• Raid force will cross Line of Departure together 

• Raid force will cross surf zone on line in one wave 

Scare 3EJ: 

Ffeccn Camclais 


Storyboard Photo 3D Screen Shot 
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10. Scene 100: Beach Landing Site 

Location: 

• Red Beach, Camp Pendleton California 
Description: 

• Raid force crosses surf zone and lands at beach landing site 
Purpose: 

• Raid force reaches the beach landing site 

• Drive inland to disembark the Marines 

• Marine squads carry out the rest of the mission 

Scene 100: 

Beadh Lar/Xiy Site 


Storyboard Photo 3D Screen Shot 

D. SUMMARY 

This chapter describes the methodology used to arrive at the end goal of 
generating the 3D amphibious-raid. In order to keep the scenario realistic, yet remain 
simple at the same time, a number of assumptions and limitations are imposed. In order 
to validate the use of future platforms such as the San Antonio class LPD and the AAAV, 
it was assumed that both platforms are fielded and in use throughout the fleet. Further 
limitations to ensure scenario simplicity include lack of enemy contact, no representation 
of individual Marines, and minimal overall numbers of AAAVs, ships and helicopters. In 
order to get a visual perception of the methodology used, the chapter concludes with a 
demonstration of how the text description, storyboard, photo and 3D screen shot all work 
in parallel to embody the exact same tactical scene. 
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vm. CONCLUSIONS AND RECOMMENDATIONS 


A. INTRODUCTION 

This chapter presents conclusions drawn from the authoring and visualization 
work completed by this thesis. Recommendations for future work that benefit or add 
value to the research of this thesis are also presented. 

B. CONCLUSIONS 

Automatic generation of an operation order into a 3D virtual battlespace capable 
of displaying an amphibious-raid is feasible. The storyboarding technique is an effective 
way to generate a rich scenario and capture the elements that are considered vital to 
battlespace visualization. While the final step of automatic scene generation did not 
come to fruition for this thesis due to the need to complete a more robust XML schema 
than was available from the MTF2XML Converter, the Mark Murray and Jason Quigley 
thesis has shown that it can be done. It can’t be stressed enough that XML is the “glue” 
that makes this all possible. With the operation order format tags that the MTF2XML 
Converter provides, the Generic Hub schema that defines consistent semantic tags for the 
usable information within the GENTEXT sectio ns of the order, and a stylesheet that 
translates this information into VRML, only the number of 3D models available bound 
the visualization possibilities. While work is still necessary, this tool will prove 
invaluable in operations planning efforts. 

C. RECOMMENDATIONS FOR FUTURE WORK 
1. Standardized Operation Orders 

While it can be said that operation orders are currently standardized, based on the 

limitations of operation orders discussed in Chapter III, I would argue that they are not 
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truly standardized. In order to have one schema or document type definition to define tag 
sets that are valid across all services (and within services), required information, terms, 
and acronyms are going to have to be common for everyone. Ultimately, this would need 
to extend to annexes, SOPs, and other materials that may be referenced. While the 
Generic Hub is just a database, the concepts it employs should be enforced with regards 
to writing operation orders. Whereas the Generic Hub data definitions are agreed upon 
by the US and NATO, the US military should develop an agreed upon standard for 
writing operation orders, conceivably using Generic Hub terminology. 

2. Autogeneration of the Amphibious -raid in 3D 

It is important to continue to work on an XML schema and XSL stylesheet that 
automatically generates a 3D visualization of the amphibious-raid scenario. While the 
work is close to completion, it isn’t there yet. Continued work and collaboration with the 
XML-MTF Development Team, Naval Undersea Warfare Command, and Institute for 
Defense Analysis will ensure a robust schema is created that combines elements of 
USMTF and the Generic Hub. Once the current scenario can be autogenerated in 3D, it 
can be extended in functionality and complexity. 

3. Expand Scenario 

Once it is shown that the simple amphibious assault can be automatically 
translated from an operation order to a 3D virtual world, it is time to expand the scenario. 
In order to add the joint aspect of the current scenario and increase the complexity of the 
amphibious-raid, 3D models need to be created to include additional ships, tanks, 
bulldozers, aircraft, motor transportation assets, weapons systems, individual weapons, 
artillery, and realistic humanoids. It is essential to demonstrate the visualization of 
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complex scenarios in 3D, as this is what will most likely to be useful to warfighters using 
the tool. 

4. Expand Functionality of the Tool 

The amount of useful functionality that could be added to a tool as powerful as 
this is endless. Capabilities should be added which allow the user to control, record, and 
playback the animation as one can do with a video cassette recorder (VCR). The ability 
to toggle between the 3D world and a 2D map overlay would be useful for planners and 
commanders to see the “big picture” in one snapshot. A graphical user interface (GUI) 
that facilitates ease of authoring a scene would be a great value in decreasing the time to 
learn how to use the tool and the time to compose an order. This GUI could permit the 
author to drag and drop entities right where they are wanted on the battlefield; it could 
provide drop down menus for the addition of waypoints, calls for fire, force definitions, 
operation timelines, and specific pieces of 3D terrain. In time this tool should be coupled 
with current modeling and simulation systems to capitalize on their data. For instance, 
the Marine Corps’ MAGTF Tactical Warfare Simulation (MTWS) system already has a 
repository of scenarios that have been previously authored. If 3D scenes could be 
generated directly from the MTWS system, the need to create the same scenario again 
would be negated. 

5. Dynamic 3D Terrain Generation 

An underlying factor to the entire visualization of any virtual battlefield is the 
terrain. While Digital Terrain Elevation Data (DTED) and other 2D sources of terrain 
representations are available for most of the world, 3D data is not. A tool is needed 
which automatically generates 3D terrain from anywhere in the world by simply 


providing coordinate (grid, lat/long, etc.) input. The terrain developed for this scenario 
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was built using the Virtual Reality Toolbox. This tool, developed by Humusoft 


(www.humusoft.com) , works with the MATLAB program (www.mathworks.com) to 
generate complex 3D shapes from equations. While a tool of this caliber may have 
utilities for the 3D battlespace, it is not intuitive enough to be used to create realistic 3D 
terrain. More emphasis and research needs to be given to Geo VRML to bring the 
capability of autogenerating 3D terrain from anywhere in the world to fruition. 
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APPENDIX A. ABBREVIATIONS 


2D 

Two-Dimensional 

3D 

Three- Dimensional 

AAAV 

Advanced Amphibious Assault Vehicle 

ACE 

Air Combat Element 

AOR 

Area of Responsibility 

ARG 

Amphibious Ready Group 

ATO 

Air Tasking Order 

BDU 

Battle Dress Uniform 

BLT 

Battalion Landing Team 

CAPEX 

Capabilities Exercise 

CCIR 

Commander’s Critical Information 
Requirements 

CIO 

Chief Information Officer 

COMBAT XXI 

Combined Arms Analysis Tool for the 21 
Century 

COTS 

Commercial off the Shelf 

CSSE 

Combat Service Support Element 

DIS 

Distributed Interactive Simulation 

DoD 

Department of Defense 

DON 

Department of the Navy 

DSB 

Dynamic Scenario Builder 

DTD 

Document Type Definition 

DTED 

Digital Terrain Elevation Data 

DTG 

Date Time Group 

FSA 

Fire Support Area 

FSSG 

Force Service Support Group 

GCE 

Ground Combat Element 

GeoLOD 

Geographic Level of Detail 

GH 

Generic Hub 

GIS 

Geographic Information Systems 

GML 

Geography Markup Language 

GUI 

Graphical User Interface 

HLA 

High Level Architecture 

HTML 

Hypertext Markup Language 

IDA 

Institute for Defense Analysis 

IEEE 

Institute of Electrical and Electronic 
Engineers 

IER 

Information Exchange Requirements 

LC2IEDM 

Land Command and Control Information 
Exchange Data Model 

LCAC 

Landing Craft Air Cushioned 

LOD 

Line of Departure 

LPD 

Landing Platform Dock 
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MAGTF 

Marine Air Ground Task Force 

MCCDC 

Marine Corps Combat Development 
Command 

MEF 

Marine Expeditionary Force 

MEU 

Marine Expeditionary Unit 

MEU(SOC) 

Marine Expeditionary Unit(Special 
Operation Capable) 

MSSG 

MEU Service Support Group 

MTWS 

MAGTF Tactical Warfare Simulation 

NATO 

North Atlantic Treaty Organization 

NEO 

Non-combatant Evacuation Operation 

NFA 

No Fire Area 

NMCI 

Navy-Marine Corps Internet 

NPS 

Naval Postgraduate School 

NUWC 

Naval Undersea Warfare Command 

OPORD 

Operatio n Order 

RDF 

Resource Description Framework 

SAVAGE 

Scenario Authoring and Visualization for 
Advanced Graphical Environments 

SGML 

Standard Generalized Markup Language 

SOCEX 

Special Operation Capabilities Exercise 

SOP 

Standard Operating Procedure 

SPMAGTF 

Special MAGTF 

TF 

Task Force 

TFW 

Task Force Web 

US 

United States 

USMC 

United States Marine Corps 

USMTF 

United States Message Text Format 

VCR 

Video Cassette Recorder 

VRML 

Virtual Reality Modeling Language 

W3C 

World Wide Web Consortium 

WARNORD 

Warning Order 

WWW 

World Wide Web 

X3D 

Extensible 3D 

XML 

Extensible Markup Language 

XML-MTF 

XML-Message Text Format 

XSL 

Extensible Stylesheet Language 

XSLT 

XSL Transformations 


90 



APPENDIX B. JOINT-LEVEL OPERATION ORDER 


A. INTRODUCTION 

This appendix is the joint-level operation order for the amphibious-raid written as 
a Word document. It is supplied as a typical initial reference from which the unit 
operation order is built. It is intended that future expansions of the scenario modeling 
effort build from this order. This order is not complete, nor have AOR coordinates been 
updated to reflect the working scenario since it was not important to do so in support of 
this thesis. Nevertheless, this operation order contains sufficiently detailed information 
to fully model an exemplar amphibious-raid. 

B. JOINT LEVEL OPERATION ORDER 

FM CJTF BLUE 
TO 

COMTHIRDFLT N3 
CTF ONE SEVEN FIVE 
CTF ONE SEVEN SIX 
CTF ONE SEVEN SEVEN 
CTF ONE SEVEN EIGHT 
COMDESRON TWO ONE 
MSSG ONE FIVE 
ZEN/BLT ONE SLANT FOUR 
ZEN/HMM ONE SIX SIX 
USS SHILOH 
USS STETHEM 
USS HIGGINS 
USS BREMERTON 
COT USS ESSEX 
COT USS DENVER 
COT USS PEARL HARBOR 

INFO 

BT 

UNCLAS //N03500// 

EXER/XML01// 

MSGID/GENADMIN// 

SUBJ/OPERATIONS ORDER FOR AMPHIBIOUS-RAID// 

EXERCISE EXERCISE EXERCISE// 

REF/AWARNORD/JCS/011000Z JAN 01// 

AMPN/REF A IS JCS WARNORD TO CONDUCT AMPHIB RAID// 

NARR/ // 

RMKS/ 

TIME ZONE: ZULU 
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REFERENCE: (A) MAP: COMBAT TRAINING CHART, CAMP JOSEPH H. 

PENDLETON, DMAHTC SERIES V795, EDITION 1975, 1:50,000 

(B) MAP: DIGITAL TERRAIN ELEVATION DATA (DTED) 

LEVEL 1. SERIES: TCD, ITEM DTED 128, EDITION: 005 

(C) MAP: ARC DIGITIZED RASTER GRAPHICS, SERIES: 
ARC8, STOCK NO. ARC8 809055, EDITION:1. 

OPERATION ORDER 1-01 (EXERCISE XML01 AMPHIBIOUS-RAID) 

BASIC ORDER 

1. SITUATION. 

A. GENERAL. CONTINUED FIGHTING IN KOALA BETWEEN SNAKE NATIONAL 
FORCES AND APEAN SEPARATISTS HAS RESULTED IN THE DISPLACEMENT 
OF THOUSANDS OF KOALAN NON-COMBATANTS. THE NON-COMBANTANTS 
HAVE ATTEMPTED TO FLEE TOWARDS THE APEAN AND MONKEY BORDERS. 
THIS HAS CAUSED HEIGHTENED TENSIONS ALONG THE APEAN/KOALAN 
BORDER. TO SUPPORT PEACEKEEPING OPERATIONS ALONG THE BORDER, A 
FORWARD OPERATING BASE IS REQUIRED IN APE. WHILE THE APEAN 
GOVERNMENT SUPPORTS ESTABLISHMENT OF THE AIRFIELD THE REACTION 
OF THE CIVILIAN POPULATION IS UNKNOWN AND STATE 
POLICE/MILITARY CAPABILITIES ARE LIMITED. IT IS THEREFORE 
NECESSARY TO SECURE THE AIRFIELD PRIOR TO STAGING AIRCRAFT. 

B. BATTLESPACE. 

(1) JOINT OPERATIONS AREA/HIGHER COMMANDER'S AREA OF 
OPERATIONS: (GIVE BOX WHICH INCLUDES AREA) 

(2) AREA OF INTEREST. APE LITTORAL AREA. 

(3) AREA OF OPERATION 

i. N33DEG 20.00MIN/W118DEG 00.00MIN 
ii. N33DEG 00.00MIN/W117DEG 40.00MIN 
iii . N33DEG 10.00MIN/W117DEG 00.00MIN 
iv. N33DEG 36.00MIN/W117DEG 00.00MIN 

C. ENEMY FORCES. OPPOSING FORCES CONSIST OF LOCAL ETHNIC GROUPS 
SYMPATHETIC TO SNAKE OBJECTIVES, ISLAMIC FUNDAMENTAL TERRORIST 
ORGANIZATIONS AND DISGRUNTLED STUDENTS AND WORKERS. THE MORE 
VIOLENT FORCES ARE EQUIPPED WITH AK-47'S AND EXPLOSIVES. THE 
LESS ORGANIZED GROUPS ARE EQUIPPED WITH CLUBS AND KNIVES. MOST 
OF THESE GROUPS HAVE TACTICAL AND CELLULAR COMMUNICATIONS 
EQUIPMENT AND A STRONG MESSENGER SYSTEM. MULTIPLE INTEL 
SOURCES INDICATE THAT THE POPULATION IS CONCENTRATED TO THE 
SOUTH IN THE CITY OF CARLSDAD. 

D. FRIENDLY FORCES. 

(1) HIGHER. 

1. MISSION. O/O CTF 176 CONDUCTS AN AMPHIBIOUS- 
RAID INTO THE COUNTRY OF APE TO SECURE THE 
APE AIRFIELD AND PROVIDE SECURITY FOR FOLLOW 
ON AIR COMBAT ELEMENTS, 
a. INTENT. 

i. PURPOSE/METHOD. THE PURPOSE OF 
THIS OPERATION IS TO SECURE THE 
APE AIRFIELD IOT ESTABLISH A 
FORWARD OPERATING BASE. THIS 
WILL BE ACCOMPLISHED BY AN 
AMPHIBIOUS-RAID FROM ARG 
SHIPPING. 

ii. ENDSTATE. THE ENDSTATE OF THE 

OPERATION IS TO HAVE BLUE FORCES 
IN CONTROL OF THE AIRFIELD AND 
MEU FORCES RETURNED SAFELY TO 
ARG SHIPPING. 
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(2) ADJACENT. NONE 

(3) SUPPORTING. 

(A) TACON TO CJTF BLUE 

(1) USS SHILOH 

(2) USS STETHEM 

(3) USS HIGGINS 

(B) ATTACHMENTS AND DETACHMENTS. NONE 

(C) ASSUMPTIONS. OMITTED. 

(D) LEGAL CONSIDERATIONS. 

(4) RULES OF ENGAGEMENT. REFER TO ANNEX C 

2. MISSION. IAW REF A, CJTF BLUE CONDUCTS A LIMITED AMPHIBIOUS- 
RAID INTO THE COUNTRY OF APE IOT SECURE APE AIRFIELDIN VIC OF N33DEG 
18.00MIN LAT/ W117DEG 21.00MIN LONG AND MAINTAIN AIRFIELD SECURITY 
UNTIL RELIEVED BY CTF 175 (TF APACHE). 

3. EXECUTION. 

A. COMMANDER'S INTENT. 

1. PURPOSE. THE PURPOSE OF THIS OPERATION IS TO SECURE THE 
AIRFIELD IOT ESTABLISH THE AIRFIELD AS A FORWARD 
OPERATING BASE TO SUPPORT PEACEKEEPING EFFORTS ALONG THE 
APEAN/KOALAN BORDER. 

2. METHOD. CJTF BLUE WILL CONDUCT A LIMITED AMPHIBIOUS-RAID 
TO CONTROL THE AIRFIELD. ENVIRONMENT IS ASSUMED TO BE 
PERMISSIVE. ONCE AIRFIELD IS SECURED AND TURNED OVER TO 
FOLLOW ON FORCES CJTF BLUE WILL REEMBARK ARG SHIPPING 
AND BE PREPARED TO RESPOND TO ANY FURTHER TASKING. 

3. ENDSTATE. ATF OBJECTIVE A SECURED AND CONTROLLED BY CTF 
175. MEUFORCES REEMBARKED ABOARD ARG SHIPPING. 

B. CONCEPT OF OPERATIONS. 

1. SCHEME OF MANEUVER. 

i. PHASE I. PRE-ASSAULT OPERATIONS (D-2 TO D-DAY). 

CTF 176 CONDUCTS AERIAL RECONNAISSANCE WITH COBRA 
HELOS IOT DEVELOP THE SITUATION AND PROVIDE BLS ON 
D-DAY FOR SURFACE ASSAULT FORCES. 

1. ENDSTATE. POSITIVE ID OF BLS AND OPPOSING 
FORCES. 

ii. PHASE II. ASSAULT (D-DAY TO D+l). AT H-HR ON D- 
DAY, CTF 176 CONDUCTS AN AAAV RAID SUPPORTED BY 
HELIBORNE RECON ELEMENTS ACROSS DESIGNATED 
BEACHES. AAAV CONDUCTS VEHICLE PATROL TO AIRFIELD 
SUPPORTED BY HELOS. GCE SECURES AIRFIELD. 

1. ENDSTATE. AIRFIELD SECURED, CONTROL OF 
AIRFIELD ESTABLISHED. ACE REMAINS AFLOAT, 
iii . PHASE III. FOLLOW ON FORCES OPERATIONS (D + l TO 
COMPLETION). CTF 176 MAINTAINS AIRFIELD SECURE, 
RECEIVES CTF 175 AIRCRAFT. 

1. ENDSTATE. SUCCESSFUL RECEIPT OF CTF 
175AIRCRAFT AND PERSONNEL. 

iv. PHASE IV. WITHDRAWAL. CTF 176 CONDUCTS AMPHIBIOUS 
WITHDRAWAL FROM AIRFIELD ACROSS THE BEACH TO ARG 
SHIPPING. 

1. ENDSTATE. ALL FORCES RECOVERED ABOARD ARG 
SHIPPING. 

2. FIRE SUPPORT PLAN. REFER TO ANNEX C 
(OPERATIONS). 

C. TASKS 

a. COMMAND ELEMENT R&S. NONE 

b. FCE. NONE 
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c. GCE. 

i. PHASE I. PRE-ASSAULT OPERATIONS 

1. SUPPORTING EFFORT 

ii. PHASE II. ASSAULT OPERATIONS 

1. MAIN EFFORT 

2. ON D-DAY AT H-HOUR, CONDUCT AN AMPHIBIOUS- 
RAID OVER DESIGNATED BEACHES. 

3. SEIZE ATF OBJECTIVE A 

4. MAINTAIN SECURITY 
iii . PHASE III. FOFO 

1. SUPPORTING EFFORT 

2. CONDUCT SECURITY OPERATIONS 

3. RECEIVE CTF 175 

iv. PHASE IV. WITHDRAWAL 

1. O/O, RECOVER ABOARD ARG SHIPPING 

d. ACE 

i. PHASE I. PRE-ASSAULT OPERATIONS 

1. MAIN EFFORT 

2. PROVIDE VISUAL RECONNAISSANCE 

3. IDENTIFY BLS AND PRIMARY INGRESS/EGRESS 
ROUTES 

ii. PHASE II. ASSAULT OPERATIONS 

1. SUPPORTING EFFORT 

2. PROVIDE RWCAS RAID SUPPORT FOR MAIN EFFORT 

3. PROVIDE C2 SUPPORT FOR COMM RELAY WITH THE 
MAIN EFFORT 

4. PROVIDE R&S SUPPORT FOR GCE DURING INGRESS 
TO ATF OBJECTIVE A 

iii. PHASE III. FOFO 

1. SUPPORTING EFFORT 

2. PROVIDE ON-CALL CAS AND R&S SUPPORT 

iv. PHASE IV. WITHDRAWAL 

1. PROVIDE RWCAS AND VEHICLE ESCORT IN SUPPORT 

OF THE AMPHIBIOUS WITHDRAWAL 

2. PROVIDE ASSAULT SUPPORT IN SUPPORT OF THE 
AMPHIBIOIUS WITHDRAWAL 

e. CSSE 

i. PHASE I. PRE-ASSAULT OPERATIONS 

1. SUPPORTING EFFORT 

2. CONDUCT MAINTENANCE ON MEU ASSETS AS 
REQUIRED 

3. PROVIDE SEA BASED SUSTAINMENT TO THE MAIN 
EFFORT AS REQUIRED 

4. ASSUME REAR AREA COMMANDER 
ii. PHASE II. ASSAULT OPERATIONS 

1. SUPPORTING EFFORT 

2. ESTABLISH AND CONDUCT LFSP OPERATIONS AT 
DESIGNATED RAID BEACHES 

iii. PHASE III. FOFO 

1. MAIN EFFORT 

2. CONTINUE TO CONDUCT LFSP OPERATIONS AT 
DESIGNATED RAID BEACHES 

3. FORM A MCSS DETACHMENT AND PROVIDE 
SUSTAINMENT TO SUPPORTING EFFORTS AS 
REQUIRED 

4. ACCEPT TACON OF GCE SECURITY FORCES 
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5. BPT MOVE ELEMENTS OF THE SUPPORTING EFFORTS 
AS REQUIRED 

6. BPT PROVIDE MAINTENANCE CONTACT TEAMS IN 
SUPPORT OF THE MAIN EFFORT 

iv. PHASE IV. WITHDRAWAL 

1. CONDUCT LFSP AT DESIGNATED BEACH FOR 
AMPHIBIOUS WITHDRAWAL OF FORCES. 

2. ON ORDER, RECOVER ABOARD ARG SHIPPING 

D. RESERVE. GCE WILL MAINTAIN A MOBILE RESERVE ON SHIP 

E. COMMANDERS CRITICAL INFORMATION REQUIREMENTS 

a. PIR 

i. TO KNOW THE SIZE, LOCATION, AND DISPOSITION OF 
HOSTILE FACTIONS IVO THE BLS, INGRESS/EGRESS 
ROUTES AND AIRFIELD 

ii. TO KNOW ANY OBSTRUCTIONS OR OBSTACLES IVO RAID 
BEACHES/HLZS. 

b. FFIR 

i. REPORT WHEN A UNIT SUSTAINS CASUALITIES IN 
PERSONNEL OR MAJOR END ITEMS 
ii. REPORT IF ACE READINESS DROPS BELOW 75 % 

C. EEFI 

i. CONCEAL THE COMM PLAN 
ii. CONCEAL THE SCHEME OF MANUEVER 
iii . CONCEAL HLZ'S AND ROUTES TO THE OBJECTIVE AREA 
iv. CONCEAL AIR/SURFACE INGRESS/EGRESS ROUTES 
v. CONCEAL H-HOUR AND D-DAY 
vi . FORCE/COMMAND STRUCTURE RELATIONSHIPS 
vii . ROE 

F. COORDINATING INSTRUCTION 

a. D-DAY 04JUL01 

b. H-HOUR=1500Z 

C. L-HOUR=ON CALL 

d. RED BEACH LOCATION (11SMG572830) 

e. OBJECTIVE A: APE AIRFIELD (CAMP PENDLETON) (11SMG670845) 

4 . ADMINSTRATION AND LOGISTICS 

A. PERSONNEL OMITTED 

B. LOGISTICS SEE CSSE OPORDER 

C. PUBLIC AFFAIRS OMITTED 

D. CIVIL AFFAIRS 

a. REQUESTS FOR POLITICAL ASYLUM WILL NOT BE GRANTED 

E. METEOROLOGICAL AND OCEANOGRAPHIC SERVICES METOC UPDATES WILL 
BE PROVIDED DAILY 

F. GEOSPATIAL INFORMATION AND SERVICES OMITTED 

G. MEDICAL SERVICES SEE CSSE OPORDER 

5 . COMMAND AND SIGNAL 

A. COMMAND RELATIONSHIPS 

B. COMMAND POSTS AND HEADQUARTERS 

C. SUCCESSION TO COMMAND 

D. SIGNAL. REFER TO OPTASK COMMS MESSAGE.// 

BT 

#1234 

NNNN 
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APPENDIX C. ANNEX C FOR AMPHIBIOUS-RAID 


A. INTRODUCTION 

This is Annex C to the joint operation order. It is intended to show that much 
information comes from sources outside the physical operation order. It may be used as a 
tool for future modeling and scenario development related to the efforts of this thesis. 

This annex is not complete, nor have FSA and NFA coordinates been updated to reflect 
the working scenario, as it was not important to do so in support of this thesis. 
Nevertheless, sufficient detail is included to accurately model an exemplar amphibious- 
raid along with supporting ship and aircraft operations. 

B. ANNEX C 

FM CTF ONE SEVEN SIX 
TO MSSG ONE FIVE 
ZEN/BLT ONE SLANT FOUR 
ZEN/HMM ONE SIX SIX 
INFO CJTF BLUE 
COMTHIRDFLT N3 
COMDESRON TWO ONE 
CTF ONE SEVEN FIVE 
CTF ONE SEVEN SEVEN 
CTF ONE SEVEN EIGHT 
USS SHILOH 
USS STETHEM 
USS HIGGINS 
USS BREMERTON 
COT USS ESSEX 
COT USS DENVER 
COT USS PEARL HARBOR 
BT 

UNCLAS //N03500// 

EXER/XML01// 

MSGID/GENADMIN// 

SUBJ/OPERATIONS ANNEX FOR AMPHIBIOUS-RAID// 

EXERCISE EXERCISE EXERCISE// 

REF/A/WARNORD/CJTF BLUE/011000Z JAN 01// 

AMPN/REF A IS CJTF BLUE WARNORD TO CONDUCT AMPHIB RAID// 

NARR/ 

RMKS/ 

TIME ZONE: ZULU 

REFERENCE: (A) MAP: COMBAT TRAINING CHART, CAMP JOSEPH H. 

PENDLETON, DMAHTC SERIES V795, EDITION 1975, 1:50,000 

(B) OPERATION ORDER 1-01 (EXERCISE XML01 AMPHIBIOUS-RAID) 
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ANNEX C TO OPERATION ORDER 1-01 (EXERCISE XML01 AMPHIBIOUS-RAID) 
OPERATIONS 

1. GENERAL. THIS ANNEX PROVIDES GUIDANCE FOR THE CONDUCT OF 
OPERATIONS. 

A. SITUATION. REFER TO THE BASIC ORDER. 

B. MISSION. REFER TO THE BASIC ORDER. 

C. AREA OF OPERATIONS. REFER TO THE BASIC ORDER. 

2. CONCEPT OF OPERATIONS. REFER TO THE BASIC ORDER. 

3 . CONDUCT OF OPERATIONS. 

A. AVIATION OPERATIONS. 

a. ATO PUBLISHED DAILY BY JFACC (CCDG-3) VIA CLASSIFIED 
MESSAGE TRAFFIC 

b. ACO PUBLISHED DTG 021640Z DEC 00 VIA UNCLASS MESSAGE 
TRAFFIC. 

C. ATTACK AVIATION PLANNING GUIDANCE FOR D-DAY. 

i. RWCAS: 1430Z - 2030Z 2 X AH-1Z ON STATION. THESE 

AIRCRAFT WILL PROVIDE LANDING SUPPORT AND 
COMMUNICATIONS SUPPORT FOR THE GCE TO THE BLS. 
FURTHER R&S SUPPORT WILL BE PROVIDED TO GCE DURING 
INGRESS TO OBJECTIVE A. 

d. ATTACK AVIATION PLANNING GUIDANCE FOR D+l. 

i . RWCAS: 

1. AT 2300Z, ONE SIMCAS SECTION AH-1Z ASSUMES 
15M ALERT, ONE SIMCAS SECTION AH-1Z ASSUMES 
60M ALERT. SUBMIT JTARS FOR SUPPORT. 

2. AT 0030Z, IF ALERT AIRCRAFT HAVE NOT BEEN 
TASKED, ONE SECTION AH-1Z LAUNCHES AND IS ON 
STATION FROM 0030Z TO 0200Z. SAME SECTION 
THEN RTB. ADDITIONALLY, ONE SECTION AH-1Z 
ASSUMES 15M ALERT. SUBMIT JTARS FOR 
SUPPORT. 

3. AT 0200Z, IF ALERT AIRCRAFT HAVE NOT BEEN 
TASKED, ONE SECTION AH-1Z LAUNCHES AND IS ON 
STATION FROM 0200Z TO 0330Z. SAME SECTION 
THEN RTB. 

4. AT 0330Z, IF ALERT AIRCRAFT ARE NOT TASKED, 
AIRCRAFT REMAIN ON BOAT AVAILABLE FOR 
TASKING. 

e. ALL OTHER AVIATION OPERATIONS ARE PER THE BASIC ORDER 
AND CO, HMM ONE SIX SIX OPERATION ORDER. 

B. MARITIME PREPOSITIONING FORCE OPERATIONS. 

C. INFORMATION OPERATIONS, COMMAND AND CONTROL WARFARE. 

a. FRIENDLY COMMAND AND CONTROL WARFARE READINESS. STRICT 
"NO CLUTTER" USES OF ALL ARG/MEU NETS IS CRITICAL. 
CELLULAR PHONES, UNSECURED NETS, POTS LINES AND SAILOR 
PHONES WILL NOT BE USED AT ANY TIME DURING THIS 
OPERATION. 

D. COUNTERINSURGENCY. OMITTED. 

E. NUCLEAR OPERATIONS. OMITTED. 

F. NBC DEFENSE OPERATIONS. OMITTED. 

G. SPECIAL OPERATIONS. OMITTED. 

H. TACTICAL RECOVERY OF AIRCRAFT AND PERSONNEL. REFER TO THE 
BASIC ORDER. 

I. RULES OF ENGAGEMENT. 

a. CJCS STANDING AND USPACOM SUPPLEMENTAL ROE APPLY. 
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b. OFFENSIVE MILITARY OPERATIONS ARE AUTHORIZED IN ATF 

OBJECTIVE A AGAINST ANY FORCES OPPOSING SEIZURE OF THESE 
OBJECTIVES. 

C. ENTRY INTO THE FOREIGN LAND TERRITORY, INTERNAL WATERS, 
AND AIRSPACE OF APE IS AUTHORIZED. 

d. CTF 176 IS DELEGATED AUTHORITY TO EXERCISE NATIONAL SELF 
DEFENSE. 

e. USE OF RIOT CONTROL AGENTS (RCA), SPECIFICALLY CS GAS 
AND PEPPER SPRAY ONLY, IS AUTHORIZED TO CONTROL 
NONCOMBATANT INDIVIDUALS AND GROUPS AS RIOT AND CROWD 
CONTROL AS NECESSARY. 

J. RECONNAISSANCE. REFER TO R&S CONOPS AND CONFIRMATION BRIEFS. 

K. AIR BASE OPERABILITY. OMITTED. 

L. COMBAT CAMERA. OMITTED. 

M. NONCOMBATANT EVACUATION OPERATIONS. REFER TO THE BASIC ORDER. 

N. ESCAPE AND EVASION OPERATIONS. REFER TO R&S CONOPS AND 
CONFIRMATION BRIEFS. 

O. COUNTERATTACK. OMITTED. 

P. EXPLOSIVE ORDNANCE DISPOSAL. OMITTED. 

Q. AMPHIBIOUS OPERATIONS. REFER TO CTF 176 OPTASK AMPHIB FOR 
AMPHIBIOUS-RAID XML01 DTG 101700Z NOV 00 ISSUED VIA CLASSIFIED 
MESSAGE TRAFFIC AND TO THE LANDING PLAN FOR THIS OPERATION. 

R. FORCE PROTECTION. REFER TO THE BASIC ORDER. 

S. REAR AREA OPERATIONS. PER CSSE OPERATION ORDER. 

T. FIRE SUPPORT. 

a. ASSETS 

(1) ARTILLERY BATTERY WILL BE EMPLOYED IN A NON 
LETHAL CAPACITY DURING THIS OPERATION 

(2) R/W CAS: 2 X AH-1Z 

(3) USS STETHEM, 2 X 5"54. 

b. AIR SUPPORT. REFER TO PARAGRAPH 3.A OF THIS ANNEX. 

C. ARTILLERY SUPPORT. OMITTED 

d. NAVAL SURFACE FIRE SUPPORT. USS STETHEM WILL TRANSIT TO 
FSA 1 IMMEDIATELY PRIOR TO H-HOUR AND WILL BE ON-STATION 
FOR THE DURATION OF OPERATIONS ASHORE. 

e. FIRE SUPPORT COORDINATION. 

(1) METHOD. INITIALLY, THE SACC WILL ACT AS THE 
PRINCIPLE FIRE SUPPORT COORDINATION CENTER FOR 
THE AREA OF OPERATIONS. AS SOON AS THE GCE FSCC 
IS ABLE TO CONDUCT FIRE SUPPORT COORDINATION IN 
ZONE, RESPONSIBILITY FOR FIRE SUPPORT 
COORDINATION IN ZONE WILL BE PHASED ASHORE. 

AFATDS WILL BE THE PRIMARY MEANS OF REQUESTING 
AND COORDINATING SURFACE FIRE SUPPORT THROUGHOUT 
THE OPERATION. INITIALLY, ALL DIGITAL CALLS FOR 
FIRE WILL ROUTE THROUGH THE SACC TO THE FIRING 
UNITS. ROUTING OF CALLS FOR FIRE WILL TRANSITION 
TO THE GCE FSCC ONCE IT IS CAPABLE OF PROCESSING 
MISSIONS. ANY VOICE CALLS FOR FIRE WILL ROUTE 
DIRECTLY TO THE FIRING UNIT. THE GCE WILL 
MONITOR, CLEAR AND DECONFLICT VOICE FIRE REQUESTS 
IF ABLE. IF THE GCE IS UNABLE, REQUESTS FOR 
CLEARANCE WILL BE ROUTED TO THE SACC VIA THE LF 
FSC 2 VOICE NET. WHENEVER POSSIBLE, AND IN THE 
ABSENCE OF COMMUNICATIONS WITH HIGHER AGENCIES, 
FIRE SUPPORT COORDINATION WILL BE CONDUCTED AT 
THE LOWEST POSSIBLE LEVEL. 
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(2) FIRE SUPPORT COORDINATION MEASURES AND 
GEOMETRY. 

1. FSA ONE. 

US MG463916 
IIS MG521844 
US MG491821 
IIS MG434853 

2. FSA TWO. 

IIS MG568784 
IIS MG636697 
US MG607675 
US MG537762 

3. ZONES OF ACTION. REFER TO APPENDIX 18 


(OPERATIONS OVERLAY). 


NFA'S. ALL NFA'S ARE VALID AS OF 032000Z 


JAN 01. ALL NFA'S AROUND OP'S ARE 250M RADIUS. 


(a) 

NFA1 

11SMG4 8 9008 

SS2 

(b) 

NFA2 

11SMG4 8 9 9 6 9 

SS3 

(c) 

NFA3 

11SMG5 8 5 8 67 

SSI 

(d) 

NFA4 

11SMG631850 

BLT3 

(e) 

NFA5 

11SMG62 67 5 0 

BLT2 

(f) 

NFA6 

11SMG5 7 0 82 8 

NSWTU 


5. AIRSPACE COORDINATION MEASURES. REFER 
TO AIR CONTROL ORDER OR APPENDIX 18. 

f. ATTACK GUIDANCE. PUBLISHED VIA SEPCOR. 

g. FIRE SUPPORT COMMUNICATIONS. THE SACC WILL MONITOR 
THE FOLLOWING NETS. 


(1) NAVAL GUNFIRE GROUND SPOT. 

(2) TAR HR 

(3) LF FSC 2. PRIMARY VOICE FSC NET AND COF 
BACKUP. 

(4) LF FSC 3. PRIMARY DIGITAL AFATDS NET. 

(5) TAD NETS AS APPLICABLE. 

U. COUNTER MECHANIZED PLAN. OMITTED. 

V. BREACHING PLAN. OMITTED. 

W. OBSTACLE PLAN. OMITTED. 

4. OPERATIONAL CONSTRAINTS. OMITTED. 

5. COMMAND AND SIGNAL. 

A. COMMAND. REFER TO THE BASIC ORDER 

B. SIGNAL. REFER TO OPTASK COMMS MSG FOR XML01.// 


BT 

#1234 

NNNN 
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APPENDIX D. UNIT OPERATION ORDER 


A. INTRODUCTION 

This appendix is the unit-level operation order for the amphibious-raid written as 
a word document. It is the focus order from which follow on orders were modified for 
purposes of this thesis. Future additions and expansions of this order to increase 
complexity at the unit-level can build on this order. This order contains enough 
information to understand the scenario and support the goals of this thesis. 

B. UNIT OPERATION ORDER 

FM BLT ONE SLANT FOUR 
TO COMPANY ALPHA 
COMPANY BRAVO 
INFO CJTF BLUE 
CTF ONE SEVEN SIX 
CTF ONE SEVEN FIVE 
CTF ONE SEVEN SEVEN 
CTF ONE SEVEN EIGHT 
COMTHIRDFLT N3 
COMDESRON TWO ONE 
MSSG FIFTEEN 
ZEN/HMM ONE SIX SIX 
USS SHILOH 
USS STETHEM 
USS HIGGINS 
USS BREMERTON 
COT USS ESSEX 
COT USS DENVER 
COT USS PEARLHARBOR 
BT 

UNCLAS//N03500// 

EXER/XML01// 

MSGID/GENADMIN// 

SUBJ/MEU OPERATIONS ANNEX FOR AMPHIBIOUS-RAID// 

EXERCISE EXERCISE EXERCISE// 

REF/A/OPORD/CJTF BLUE/010100Z JAN 01 

AMPN/REF A IS CJTF BLUE OPORD TO CONDUCT AMPHIB RAID 
NARR/THIS IS MEU OPERATIONS ANNEX IN SUPPORT OF 
XML01// 

RMKS/ 

TIME ZONE: ZULU 

REFERENCE:(A) MAP: COMBAT TRAINING CHART, CAMP JOSEPH H. 
PENDLETON, DMAHTC SERIES V795, EDITION 1975,1:50,000 

(B) MAP: DIGITAL TERRAIN ELEVATION DATA (DTED) LEVEL 1. SERIES: 
TCD, ITEM DTED 128, EDITION: 005 

(C) MAP: ARC DIGITIZED RASTER GRAPHICS, SERIES: ARC8, STOCK NO. 
ARC8 809055, EDITION: 1. 
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(D) OPERATION ORDER 1-01 (EXERCISE XML01 AMPHIBIOUS-RAID) 

(E) ANNEX C TO OPERATION ORDER 1-01 (EXERCISE XML01 AMPHIBIOUS- 

RAID) 

(F) BATTALION ORDER P3000 (COMBAT SOP) 

1. SITUATION. 

A. GENERAL. REFER TO BASIC ORDER. 

B. ENEMY FORCES. REFER TO BASIC ORDER. 

C. FRIENDLY FORCES. REFER TO BASIC ORDER 

D. ATTACHMENTS AND DETACHMENTS. ANNEX A (TASK ORGANIZATION) 

2. MISSION. AT H-HOUR, BLT 1/4 CONDUCTS AN AAAV RAID ACROSS RED 

BEACH AND PROCEEDS INLAND TO SEIZE ATF OBJECTIVE A. ONCE SEIZED, 

MAINTAIN SECURITY OF OBJECTIVE UNTIL RELIEVED BY TF APACHE. 

3. EXECUTION. 

A. COMMANDER'S INTENT AND CONCEPT OF OPERATIONS. 

1. BATTALION COMMANDERS INTENT. CURRENTLY 
THERE IS MINIMAL THREAT IN OUR ZONE. 

HOWEVER, MY CONCERN LIES IN THE FACT THAT 
CIVILIAN REACTION IS UNCERTAIN AND THERE ARE 
GREAT NUMBERS OF THEM NEARBY. AS WE ARE 
DEALING WITH A CIVILIAN GROUP, I SEE THEIR 
VULNERABILITY AS RESPONSIVENESS AND LACK OF 
TRAINING. I INTEND TO EXPLOIT THIS BY 
LANDING EARLY IN THE MORNING AN MOVING TO 
THE OBJECTIVE QUICKLY BEFORE THE GENERAL 
POPULACE IS AWAKE. 

2. ENDSTATE. I SEE OUR ENDSTATE AS ATF 
OBJECTIVE A SECURED & IN CONTROL OF CTF 175 
(TF APACHE). 

3. CONCEPT OF OPERATIONS. AT H-HOUR, BLT 1/4 
CONDUCTS AN AMPHIBIOUS-RAID TO SEIZE ATF 
OBJECTIVE A. THREE REINFORCED PLATOONS FROM 
COMPANY A WILL CONDUCT AN AAAV ASSAULT 
ACROSS RED BEACH AND PROCEED INLAND VIA 
PREDETERMINED ROUTE TO SEIZE ATF OBJECTIVE 
A. COMPANY A WILL SECURE THE OBJECTIVE AND 
REMAIN UNTIL RELIEVED BY TF APACHE. COMPANY 
B IS THE RESERVE. COMPANY A IS THE MAIN 
EFFORT AND WILL HAVE PRIORITY OF FIRES FOR 
THE DURATION OF THE OPERATION. 

B. TASKS 

1. 1 st PLAT (REIN), CO A 

i. AT H-HOUR (1500Z), CONDUCT AN AAAV ASSAULT ACROSS RED 
BEACH AND CONTINUE INLAND TO SEIZE ATF OBJECTIVE A. 

ii. YOU ARE THE RECONNAISSANCE ELEMENT AND WILL LOAD IN 
AAAV 1. 

iii . ONCE YOU REACH THE BLS, YOU WILL FOLLOW IN TRACE OF 2 nd 
AND 3 rd PLATOONS WHILE DRIVING TO ATF OBJECTIVE A. 

iv. UPON CONSOLIDATION ON ATF OBJECTIVE A, ESTABLISH 

PERIMETER SECURITY IN THE VICINITY OF GRID 11SMG673842 
v. BE PREPARED TO ASSIST WITH THE TURNOVER TO TF APACHE. 


2. 2 nd PLAT (REIN), CO A 

i. AT H-HOUR, CONDUCT AN AAAV ASSAULT ACROSS RED BEACH AND 
CONTINUE INLAND TO SEIZE ATF OBJECTIVE A. 
ii. YOU ARE THE COMMAND ELEMENT AND WILL LOAD IN AAAV 2. 
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iii . ONCE YOU REACH THE BLS, YOU WILL FOLLOW IN TRACE OF 3 rd 
PLATOON WHILE DRIVING TO ATF OBJECTIVE A. 
iv. UPON CONSOLIDATION ON ATF OBJECTIVE A, ESTABLISH 

PERIMETER SECURITY IN THE VICINITY OF GRID 11SMG664839. 
v. BE PREPARED TO ASSIST WITH THE TURNOVER TO TF APACHE. 

3. 3 rd PLAT (REIN), CO A 

i. AT H-HOUR, CONDUCT AN AAAV ASSAULT ACROSS RED BEACH AND 
CONTINUE INLAND TO SEIZE ATF OBJECTIVE A. 

ii. YOU ARE THE SECURITY ELEMENT AND WILL LOAD IN AAAV 3. 

iii. UPON CONSOLIDATION ON ATF OBJECTIVE A, ESTABLISH 

PERIMETER SECURITY IN THE VICINITY OF GRID 11SMG676853. 

iv. BE PREPARED TO ASSIST WITH THE TURNOVER TO TF APACHE. 

4. BLT RESERVE: CO B 

i. AT H-HOUR, YOU ARE ON IMMEDIATE ALERT AND 
WILL BE PREPARED TO ASSUME THE MISSION OF 
THE MAIN EFFORT. 

C. COORDINATING INSTRUCTIONS 

1. D-DAY 04JUL01 

2. H-HOUR=1500Z 

3. L-HOUR=ON CALL 

4. RED BEACH LOCATION (11SMG572830) 

5. ATF OBJECTIVE A: APE AIRFIELD (CAMP PENDLETON) 

(11SMG67 0 8 4 5) 

6. REPORT INCREASED CIVIL UNREST. 

4. ADMINISTRATION AND LOGISTICS 

A. REFER TO ANNEX D (LOGISTICS). 

B. PRESCRIBED LOAD PER REF D. 

5. COMMAND AND SIGNAL 

A. SIGNAL. REFER TO REF D.// 

BT 

#1234 

NNNN 
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APPENDIX E. USMTF “ENHANCED” ORDER 


A. INTRODUCTION 

This appendix contains the same operation order as in Appendix D, but it has 
been entered into USMTF and “enhanced” to include pertinent amplifying information 
(displayed in bold text). This information includes call signs, and an entire section on 
“Timeline and Movement” which includes a number of important times, actions and 
coordinates that are not normally included in the “basic” operation order. In order to add 
this additional information, normal operation order writing criteria were slightly 
modified. 

B. USMTF ORDER 

UNCLAS 

EXER/XML01// 

MSGID/ORDER/BLT ONE SLANT FOUR// 

ORDTYP/TASKORD/-// 

TIMEZONE/Z// 

ORDREF/WARNORD/CJTF BLUE ..- 

// 


GENTEXT/SITUATION/ 

A. GENERAL. REFER TO BASIC ORDER 

B. ENEMY FORCES. REFER TO BASIC ORDER 

C. FRIENDLY FORCES. REFER TO BASIC ORDER 

D. ATTACHMENTS AND DETACHMENTS. ANNEX A (TASK 
ORGANIZATION)// 

GENTEXT/MISSION/AT H-HOUR, BLT 1/4 CONDUCTS AN AAAV RAID ACROSS 
RED BEACH AND PROCEEDS INLAND TO SEIZE ATF OBJECTIVE A. ONCE 
SEIZED, MAINTAIN SECURITY OF OBJECTIVE UNTIL RELIEVED BY TF 
APACHE.// 

GENTEXT/EXECUTION/A. COMMANDER'S INTENT AND CONCEPT OF 
OPERATIONS. 

1. BATTALION COMMANDERS INTENT. CURRENTLY THERE IS MINIMAL 
THREAT IN OUR ZONE. HOWEVER, MY CONCERN LIES IN THE FACT THAT 
CIVILIAN REACTION IS UNCERTAIN AND THERE ARE GREAT NUMBERS OF 
THEM NEARBY. AS WE ARE DEALING WITH A CIVILIAN GROUP, I SEE THEIR 
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VULNERABILITY AS RESPONSIVENESS AND LACK OF TRAINING. I INTEND 
TO EXPLOIT THIS BY LANDING EARLY IN THE MORNING AND MOVING TO THE 
OBJECTIVE QUICKLY BEFORE THE GENERAL POPULOUS IS AWAKE. 

2. ENDSTATE. I SEE OUR ENDSTATE AS ATF OBJECTIVE A SECURED 
& IN CONTROL OF CTF 175 (TF APACHE). 

3. CONCEPT OF OPERATIONS. AT H-HOUR, BLT 1/4 CONDUCTS AN 
AMPHIBIOUS-RAID TO SEIZE ATF OBJECTIVE A. THREE REINFORCED 
PLATOONS FROM COMPANY A WILL CONDUCT AN AAAV ASSAULT ACROSS RED 
BEACH AND PROCEED INLAND VIA PREDETERMINED ROUTE TO SEIZE ATF 
OBJECTIVE A. COMPANY A WILL SECURE THE OBJECTIVE AND REMAIN 
UNTIL RELIEVED BY TF APACHE. COMPANY B IS THE RESERVE. COMPANY A 
IS THE MAIN EFFORT AND WILL HAVE PRIORITY OF FIRES FOR THE 
DURATION OF THE OPERATION. 

B. TASKS 

1. ORGANIZATION 

A. AAAV COMPANY 

1. AAAV1 

A. CALL SIGN - BLUE DEVIL 

2. AAAV 2 

A. CALL SIGN - NITTANY LION 

3. AAAV 3 

A. CALL SIGN - HUSKY 

2. 1ST PLAT(REIN), CO A 

A. AT H-HOUR (1500Z), CONDUCT AN AAAV ASSAULT ACROSS RED 
BEACH AND CONTINUE INLAND TO SEIZE ATF OBJECTIVE A PER GUIDANCE 
IN SECTION 6 OF THIS ORDER. 

B. PER GUIDANCE IN SECTION 6 OF THIS ORDER, WITHDRAW TO ARG 
SHIPPING AFTER TF APACHE ASSUMES CONTROL OF THE AIRFIELD. 

C. YOU ARE THE RECONNAISSANCE ELEMENT AND WILL LOAD IN AAAV 

1 . 

3. 2ND PLAT(REIN), CO A 

A. AT H-HOUR, CONDUCT AN AAAV ASSAULT ACROSS RED BEACH AND 
CONTINUE INLAND TO SEIZE ATF OBJECTIVE A PER GUIDANCE IN SECTION 
6 OF THIS ORDER. 

B. PER GUIDANCE IN SECTION 6 OF THIS ORDER, WITHDRAW TO ARG 
SHIPPING AFTER TF APACHE ASSUMES CONTROL OF THE AIRFIELD. 

C. YOU ARE THE COMMAND ELEMENT AND WILL LOAD IN AAAV 2. 

4. 3RD PLAT(REIN), CO A 

A. AT H-HOUR, CONDUCT AN AAAV ASSAULT ACROSS RED BEACH AND 
CONTINUE INLAND TO SEIZE ATF OBJECTIVE A PER GUIDANCE IN SECTION 
6 OF THIS ORDER. 

B. PER GUIDANCE IN SECTION 6 OF THIS ORDER, WITHDRAW TO ARG 
SHIPPING AFTER TF APACHE ASSUMES CONTROL OF THE AIRFIELD. 

C. YOU ARE THE SECURITY ELEMENT AND WILL LOAD IN AAAV 3. 

5. BLT RESERVE: CO B 

A. AT H-HOUR, YOU ARE ON IMMEDIATE ALERT AND WILL BE PREPARED 
TO ASSUME THE MISSION OF THE MAIN EFFORT. 

6. TIMELINE AND MOVEMENT 

A. DEPART SHIP AT H-HOUR (INSERTION) 

1. START TIME: 041500ZJUL01 

2. START LOCATION: LAT N33DEG11.OOMIN LONG W117DEG35.OOMIN 

3. END TIME: 041800ZJUL01 

4. END LOCATION: LAT N33DEG14.9MIN LONG W117DEG25.7MIN 

B. TRANSIT TO OBJECTIVE AREA (INFIL) 

1. START TIME:041801ZJUL01 

2. START LOCATION: LAT N33DEG14.9MIN LONG W117DEG25.7MIN 

3. WAYPOINTS: 
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A. LAT N33DEG15.538MIN LONG W117DEG24.875MIN 

B. LAT N33DEG13.976MIN LONG W117DEG23.328MIN 

C. LAT N33DEG17.274MIN LONG W117DEG22.241MIN 

4. END TIME: 042100ZJUL01 

5. END LOCATION: LAT N33DEG17.885MIN LONG W117DEG21.144MIN 

C. ACTIONS AT OBJECTIVE 

A. START TIME: 042101ZJUL01 

B. END TIME: 050300ZJUL01 

1. AAAV1 

A. LOCATION: LAT N33DEG17.885MIN LONG W117DEG21.144MIN 

B. ROLE: C2 AND SECURITY 

2. AAAV2 

A. LOCATION: LAT N33DEG17.744MIN LONG W117DEG21.722MIN 

B. ROLE: SECURITY 

3. AAAV3 

A. LOCATION: LAT N33DEG18.419MIN LONG W117DEG20.919MIN 

B. ROLE: SECURITY 

D. EXFIL 

1. START TIME: 050301ZJUL01 

2. START LOCATION: LAT N33DEG17.885MIN LONG 
W117DEG21.144MIN 

3. WAYPOINTS: 

A. LAT N33DEG17.274MIN LONG W117DEG22.241MIN 

B. LAT N33DEG13.976MIN LONG W117DEG23.328MIN 

C. LAT N33DEG15.538MIN LONG W117DEG24.875MIN 

4. END TIME: 050500ZJUL01 

5. END LOCATION: LAT N33DEG14.9MIN LONG W117DEG25.7MIN 

E. EXTRACTION 

1. START TIME: 050501ZJUL01 

2. START LOCATION: LAT N33DEG14.9MIN LONG W117DEG25.7MIN 

3. END TIME: 050701ZJUL01 

4. END LOCATION: LAT N33DEG11.OOMIN LONG W117DEG35.OOMIN 

C. COORDINATING INSTRUCTIONS 

1. D-DAY 04JUL01 

2. H-HOUR=1500Z 

3. L-HOUR=ON CALL 

4. RED BEACH LOCATION (11SMG572830) 

5. ATF OBJECTIVE A: APE AIRFIELD (CAMP PENDLETON) 

(11SMG67 0 8 4 5) 

6. REPORT INCREASED CIVIL UNREST.// 

GENTEXT/AUTHENTICATION/MG PULLER 
OFFICIAL: 

(ORIGINAL SIGNED) 

DAILY OPSOFF// 

ANNEXES/ANXNO:C/OPERATION ANNEX// 

AKNLDG/YES// 
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APPENDIX F. XML-MTF ORDER 


A. INTRODUCTION 

This appendix takes the previous USMTF order and runs it through a MTF2XML 
conversion tool. The outcome is a converted USMTF to XML-MTF message. By 
looking at the GENTEXT sections, it is apparent that there are insufficient tags to capture 
any useful information since each section is lumped into a gigantic element tag. This is 
why it is important to continue to develop XML schemas that identify and capture the 
critical information. 

B. XMUMTF ORDER 

<?xml version = "1.0" ?> 

- <order> 

- <exercise_identification setid="EXER"> 

<exercise_ n ickna me >XML01</exercise_ nickname > 

</exercise_ identification > 

- <message_identification setid-'MSGI D"> 

<message_text_format_identifier>ORDER</ message_text_form 
at_ identifier 

<originator>BLT ONE SLANT FOUR</originator> 

</ messagejdentification > 

- <type_of_order setid- ORDTYP"> 

<type_of_plan_order>TASKORD</type_of_plan_order> 

<order_orig inator_and_or_ number / > 

</type_of_order> 

- <time_zone setid="TI MEZONE "> 

<time_zone_zulu >Z</time_zone_zulu > 

</time_zone> 

- <order_reference setid="ORDREF"> 

<type_of_plan_order>WARNORD</type_of_plan_order> 

- <order_originator_and_or_number> 

<military_command_authority>CJ TF 
BLUE </ military_command_authority > 

<two_character_space_filler>.. </two_character_space_filler> 
<operation_order_numbers </operation_order_number> 
<order_originator_and_or_number> 

</ o rd e r_ ref e re n ce > 

- <general_text_information setid="GENTEXT"> 

<gentext_text_indicator>SI TUATI ON</gentext_text_indicator> 
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<free_text xml: space="preserve">A. GENERAL. REFER TO 
BASI C ORDER B. ENEMY FORCES. REFER TO BASI C ORDER 
C. FRI ENDLY FORCES. REFER TO BASI C ORDER D. 
ATTACHMENTS AND DETACHMENTS. ANNEX A (TASK 
ORGANIZATION) </free text> 

</general_text_information > 

<general_text_information setid="GENTEXT"> 

<gentext_text_indicator>MI SSI ON</gentext_text_indicator> 
<free_text xml: space="preserve">AT H-HOUR, BLT 1/4 
CONDUCTS AN AAAV RAI D ACROSS RED BEACH AND 
PROCEEDS I NLAND TO SEI ZE ATF OBJ ECTI VE A. ONCE 
SEI ZED, MAI NTAI N SECURITY OF OBJ ECTI VE UNTI L 
RELI EVED BY TF APACHE. </ free text > 
</general_text_information > 

<general_text_information setid="GENTEXT"> 

<gentext_text_indicator>EXECUTI ON</gentext_text_indicator> 
<free_text xml: space="preserve">A. COMMANDER'S INTENT 
AND CONCEPT OF OPERATI ONS. 1. BATTALI ON 
COMMANDERS I NTENT. CURRENTLY THERE I S Ml Nl MAL 
THREAT I N OUR ZONE. HOWEVER, MY CONCERN LI ES I N 
THE FACT THAT CIVILIAN REACTION IS UNCERTAIN AND 
THERE ARE GREAT NUMBERS OF THEM NEARBY. AS WE 
ARE DEALING WITH A Cl VI LI AN GROUP, I SEE THEIR 
VULNERABILITY AS RESPONSIVENESS AND LACK OF 
TRAINING. I INTEND TO EXPLOIT THIS BY LANDING 
EARLY I N THE MORNI NG AN MOVI NG TO THE OBJ ECTI VE 
QUI CKLY BEFORE THE GENERAL POPULACE I S AWAKE. 2. 
ENDSTATE. I SEE OUR ENDSTATE AS ATF OBJ ECTI VE A 
SECURED & I N CONTROL OF CTF 175 (TF APACHE). 3. 
CONCEPT OF OPERATIONS. AT H-HOUR, BLT 1/ 4 
CONDUCTS AN AMPHI BIOUS-RAI D TO SEIZE ATF 
OBJ ECTIVE A. THREE REINFORCED PLATOONS FROM 
COMPANY A Wl LL CONDUCT AN AAAV ASSAULT ACROSS 
RED BEACH AND PROCEED I NLAND VI A PREDETERMI NED 
ROUTE TO SEI ZE ATF OBJ ECTI VE A. COMPANY A Wl LL 
SECURE THE OBJ ECTI VE AND REMAI N UNTI L RELI EVED BY 
TF APACHE. COMPANY B I S THE RESERVE. COMPANY A I S 
THE MAI N EFFORT AND Wl LL HAVE PRIORITY OF FI RES 
FOR THE DU RATI ON OF THE OPERATI ON. B. TASKS 1. 
ORGANI ZATI ON A. AAAV COMPANY 1. AAAV1 A. CALL 
SIGN - BLUE DEVIL 2. AAAV 2 A. CALL SIGN - NITTANY 
LION 3. AAAV 3 A. CALLSIGN - HUSKY 2. 1ST PLAT(REIN), 
CO A A. AT H-HOUR (1500Z), CONDUCT AN AAAV ASSAULT 
ACROSS RED BEACH AND CONTI NUE I NLAND TO SEI ZE 
ATF OBJ ECTI VE A PER GUI DANCE I N SECTI ON 6 OF THI S 
ORDER. B. PER GUI DANCE I N SECTI ON 6 OF THI S ORDER, 
Wl THDRAW TO ARG SHI PPI NG AFTER TF APACHE 
ASSUMES CONTROL OF THE Al RFI ELD. C. YOU ARE THE 
RECONNAI SSANCE ELEMENT AND Wl LL LOAD I N AAAV 1. 

3. 2ND PLAT(REI N), CO A A. AT H-HOUR, CONDUCT AN 
AAAV ASSAULT ACROSS RED BEACH AND CONTI NUE 
I NLAND TO SEI ZE ATF OBJ ECTI VE A PER GUI DANCE I N 
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SECTI ON 6 OF THI S ORDER. B. PER GUI DANCE I N 
SECTION 6 OF THIS ORDER, WITHDRAW TO ARG 
SHI PPI NG AFTER TF APACHE ASSUMES CONTROL OF THE 
Al RFI ELD. C. YOU ARE THE COMMAND ELEMENT AND Wl LL 
LOAD IN AAAV 2. 4. 3RD PLAT(REIN), CO A A. AT H-HOUR, 
CONDUCT AN AAAV ASSAULT ACROSS RED BEACH AND 
CONTI NUE I NLAND TO SEI ZE ATF OBJ ECTI VE A PER 
GUI DANCE I N SECTI ON 6 OF THI S ORDER. B. PER 
GUIDANCE IN SECTION 6 OF THIS ORDER, WITHDRAW TO 
ARG SHI PPI NG AFTER TF APACHE ASSUMES CONTROL OF 
THE Al RFI ELD. C. YOU ARE THE SECURITY ELEMENT AND 
Wl LL LOAD I N AAAV 3. 5. BLT RESERVE: COBA.ATH- 
HOUR, YOU ARE ON I MMEDI ATE ALERT AND Wl LL BE 
PREPARED TO ASSUME THE Ml SSI ON OF THE MAI N 
EFFORT. 6. Tl MELI NE AND MOVEMENT A. DEPART SHI P AT 
H-HOUR (INSERTION) 1. START TIME: 041500ZJ UL01 2. 
START LOCATION: LAT N33DEG11.00MI N LONG 
W117DEG35.00MI N 3. END Tl ME: 041800ZJ UL01 4. END 
LOCATI ON: LAT N33DEG14.9MI N LONG W117DEG25.7MI N 
B. TRANSIT TO OBJ ECTI VE AREA (I NFIL) 1. START 
Tl ME:041801ZJ UL01 2. START LOCATI ON: LAT 
N33DEG14.9MI N LONG W117DEG25.7MI N 3. WAYPOINTS: 
A. LAT N33DEG15.538MI N LONG W117DEG24.875MI N B. 
LAT N33DEG13.976MI N LONG W117DEG23.328MI N C. LAT 
N33DEG17.274MI N LONG W117DEG22.241MI N 4. END 
TIME: 042100ZJ UL01 5. END LOCATION: LAT 
N33DEG17.885MI N LONG W117DEG21.144MI N C. 

ACTIONS AT OBJ ECTI VE A. START Tl ME: 042101ZJ UL01 B. 
END TIME: 050300ZJUL01 1. AAAV1 A. LOCATION: LAT 
N33DEG17.885MI N LONG W117DEG21.144MI N B. ROLE: 

C2 AND SECURITY 2. AAAV2 A. LOCATION: LAT 
N33DEG17.744MI N LONG W117DEG21.722MIN B. ROLE: 
SECURITY 3. AAAV3 A. LOCATION: LAT N33DEG18.419MI N 
LONG W117DEG20.919MIN B. ROLE: SECURITY D. EXFI L 
1. START Tl ME: 050301ZJ UL01 2. START LOCATI ON: LAT 
N33DEG 17.885Ml N LONG W117DEG21.144MI N 3. 
WAYPOINTS: A. LAT N33DEG17.274MIN LONG 
W117DEG22.241MI N B. LAT N33DEG13.976MI N LONG 
W117DEG23.328MI N C. LAT N33DEG15.538MI N LONG 
W117DEG24.875MI N 4. END Tl ME: 050500ZJ UL01 5. END 
LOCATI ON: LAT N33DEG14.9MI N LONG W117DEG25.7MI N 
E. EXTRACTION 1. START TIME: 050501ZJUL01 2. START 
LOCATI ON: LAT N33DEG14.9MI N LONG W117DEG25.7MI N 
3. END Tl ME: 050701ZJ UL01 4. END LOCATI ON: LAT 
N33DEG11.00MIN LONG W117DEG35.00MI N C. 
COORDINATING INSTRUCTIONS 1. D-DAY 04J UL01 2. H- 
HOUR = 1500Z 3. L-HOUR = ON CALL 4. RED BEACH 
LOCATION (11SMG572830) 5. ATF OBJ ECTI VE A: APE 
AIRFIELD (CAMP PENDLETON) (11SMG670845) 6. 

REPORT I NCREASED Cl VI L UNREST. </ free text > 
</general_text_information > 

<general_text_information setid="GENTEXT"> 
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<gentext_text_indicator>AUTHENTI CATI ON</ gentext_text_in 
dicator> 

<free_text xml: space="preserve">MG PULLER OFFICIAL: 
(ORIGI NAL SIGNED) DAI LY OPSOFF <free_text > 
</general_text_inforrmation > 

- <annex_information setid="ANNEXES"> 

<annex_number>C </annex_number> 

<annex_name>OPERATI ON ANNEX</annex_name > 
</annex_information> 

- <acknowledgement_requirement setid="AKNLDG"> 

<acknowledgement_requirement_indicator>YES</ acknowledge 
ment_ requirement^ indicators 
</acknowledgement_requirement > 

<order> 
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APPENDIX G. OPERATION ORDER ANNEXES 


A. INTRODUCTION 

This appendix lists the number and types of annexes that can be referenced in an 
operation order. The sheer number and amount of information contained in these 
annexes add to the complexity of “grabbing” the necessary data from them. References 
may also be made to operation overlays, other orders, and SOPs which compound the 
complexity even further. 

B. LIST OF ANNEXES 

A - Task Organization 
B - Intelligence 
C - Operations 

D - Logistics/Combat Service Support 
E - Personnel 
F - Public Affairs 
G - Civil Affairs 

H - Meteorological and Oceanographic Operations 

J - Command Relationships 

K - Combat Information Systems 

L - Environmental Considerations 

M - Geospatial Information and Services 

N - Space Operations 

P - Host Nation Support 

Q - Medical Services 

S - Special Technical Operations 

U - Information Management 

W - Aviation Operations 

X - Execution Checklist 

Z - Distribution 
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APPENDIX H 


OPERATION ORDER TO 3D METHODOLOGY 


Generic Hub Design Methodology for Battlespace Visualization + Semantics: 
DoD-wide Autoconversion Of Operation Orders into 3D Virtual Environments 


Typical Operation Order: 
hand-crafted “Word 
Document” 


USMTF Message: 
Modified Operation Order 


XM L-MTF free-text Operation Order: 

Operation Order GH4 Modified XML- 

MTF 





Message Content 

Format Format 



XM L-MTF 


Operations Order, 
with GH4 -tagged 
order elements, and 
without GENTEXT 



Generic Hub version 4 (GH4) 
Information Exchange Data 
Model 





Compatible concepts, 
keyword-translatable 



US and NATO Forces. 


Generic Battlespace 
Schema for Common 
Operational/Tactical 
Picture (COP/CTP) 


Generic Hub (GH4) now 
defines an XML Schema 




X3D/VRML World: Amphibious Operation Order 
Displayed as Networked, Animated 3D Scene! 



XSL Style Sheets 


XSL Style Sheets 

T ransform 


T ransform 

OPORD 


OPORD 

XML-MTF 


XML-MTF 

converted to 


converted to 

X3D/VRMT. 


RDBMS Data Fill 




GH4 Coalition 
Operational 
Context 
Database 


Global Info Grid 


Global Systems 


Operational Context for the Global I nformation Grid: 
Smarter Applications, Agents, Autonomous Systems 


Points of Contact: Erik Chaum NUWC ChaumE@npt.nuwc.navy.mil - Francisco Loaiza ID A FLoaiza@ ida.org - Eugene Simaitis IDA GSimaiti® ida.org - Don Brutzman, Shane Nicklaus, Doug Horner NPS brutzman@ nps.navy.mil 

13 September 2001 
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APPENDIX I. OPERATION ORDER SCHEMA 


A. INTRODUCTION 

This XML schema defines the critical information required for proper 3D visualization of the order. It leverages all of the tags 
from the XML-MTF DTD that give the order it’s structure, but it contains additional elements and attributes specifically designed to 
capture the data from the TASKS section of the order. This schema is authored by Doug Horner of the Naval Postgraduate School and 
is still a work in progress. 

B. XML SCHEMA 

<?xml version="1.0" encoding = "UTF-8"?> 

<!-- edited with XML Spy v4.0 U beta 3.1 build Aug 27 2001 (http://www.xmlspy.com) by Doug Horner (Naval 
Postgraduate School) --> 

<xsd:schema xmlns:xsd="http://www. w3.org/2001/XMLSchema " elementFormDefault -'qualified "> 

<!-- Filename: OperationOrder.xsd 
Author: Doug Homer 
Created: 01AUG01 
Revised: 22SEP01 

Description: Schema for USMTF 2002 Order message. The purpose of the project is to be able to create a VRML 
scene from a USMTF message. This schema is the tagset that includes all of the "Order" message fields and then adds 
additional tags so that an XML document can "capture" the information in the USMTF GENTEXT Execution section of the Order 
formatted message and use a XSL stylesheet to convert that to VRML. This message format conforms to an exemplar USMC 
OPORDER message generated for KB01 exercise. --> 

<xsd:element name ="Order"> 

<xsd: annotation > 

<xsd: documentation >Root Element <J xsd: documentation > 

</xsd: annotation > 

<xsd:complexType> 
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<xsd:sequence> 

<xsd:element name -'Exerciseldentification" minOccurs ="0'> 

<xsd: complexType > 

<xsd:sequence> 

<xsd:element name ="ExerciseNickname "> 

<xsd:simpleType> 

<xsd: restriction base="xsd: string "> 

<xsd: minLength value="l"/> 

<xsd: maxLength value="56"/> 

</xsd: restriction > 

</xsd:simpleType> 

</xsd: element > 

<xsd:element name -'ExerciseMessageAdditionalldentifier" minOccurs ="0"> 
<xsd:simpleType> 

<xsd: restriction base- 'xsd: string' > 

<xsd: minLength value="l"/> 

<xsd: maxLength value="16"/> 

</xsd: restriction > 

</xsd:simpleType> 

</xsd: element > 

</xsd:sequence> 

<xsd: attribute name ="setid" type="xsd: string" use="required" fixed ="EXER"/> 

<xsd: attributeGroup ref="startTime "/> 

<xsd: attributeGroup ref -'endTime "/ > 

<xsd: attribute name - 'name " type="xsd: anySimpleType" use="optional"/> 

<xsd: attribute name - 'action I d Number" type="xsd: anySimpleType 1 use -'optional"/ > 
</ xsd: complexType> 

</xsd: element > 

<xsd:element name ="OperationldentificationData" minOccurs ="0 "> 

<xsd: complexly pe> 

<xsd:sequence> 

<xsd:element name ="OperationCodeword "> 

<xsd:simpleType> 

<xsd: restriction base="xsd: string "> 

<xsd: minLength value="l"/> 
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<xsd: maxLength value="32"/> 

</xsd: restriction > 

</xsd:simpleType> 

</xsd: element > 

<xsd:element name ="PlanOriginatorAndNumber" minOccurs ="0"> 

<xsd:simpleType> 

<xsd: restriction base-'xsd: string "> 

<xsd: minLength value="5"/> 

<xsd: maxLength value="36"/> 

</ xsd: restriction > 

</xsd:simpleType> 

</ xsd: element > 

<xsd:element name ="OptionNickname" minOccurs ="0"> 

<xsd:simpleType> 

<xsd: restriction base="xsd: string l! > 

<xsd: minLength value="l"/> 

<xsd: maxLength value="23"/> 

</xsd: restriction > 

</xsd:simpleType> 

</ xsd: element > 

<xsd:element name ="SecondaryOptionNickname" minOccurs ="0"> 

<xsd:simpleType> 

<xsd: restriction base="xsd: string "> 

<xsd: minLength value="l"/> 

<xsd: maxLength value="23"/> 

</xsd: restriction > 

</xsd:simpleType> 

</ xsd: element > 

</xsd:sequence> 

<xsd: attribute name="setid" type="xsd:string" use="required" fixed="OPER"/> 

<xsd: attribute name - 'operationDescription" type="xsd: anySimpleType" use="optional"/ > 
<xsd: attribute name ="objectl tern I dN umber" type="xsd: anySimpleType use="optional"/> 
<xsd: attribute name ="name " type- 'xsd: anySimpleType" use="optional"/> 

<xsd: attributeGroup ref="startTime "/> 

<xsd: attributeGroup ref ="endTime "/ > 
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<xsd: attribute name - 'name " type="xsd: anySimpleType" use="optional'7> 

<xsd: attribute name - 'actionI dNumber" type="xsd: anySimpleType 1 use -'optional"/ > 

</ xsd: complexType> 

</xsd: element > 

<xsd:element name -'Messageldentification "> 

<xsd: complexType> 

<xsd:sequence> 

<xsd:element name ="MessageTextFormatldentifier"> 

<xsd:simpleType> 

<xsd: restriction base="xsd: string "> 

<xsd: minLength value="2"/> 

<xsd: maxLength value="20"/> 

</xsd: restriction > 

</xsd:simpleType> 

</ xsd: element > 

<xsd:element name ="Originator"> 

<xsd:simpleType> 

<xsd: restriction base="xsd: string "> 

<xsd: minLength value="l"/> 

<xsd: maxLength value="30"/> 

</xsd: restriction > 

</xsd:simpleType> 

</ xsd: element > 

<xsd:element name -'MessageSerialNumber" minOccurs ="0"> 

<xsd:complexType> 

<xsd: simpleContent > 

<xsd: extension base="xsd: integer"> 

<xsd: attribute name -'referencel dNumber" type="xsd: anySimpleType ' use="required"/> 
</ xsd: extension> 

</ xsd: simpleContent> 

</xsd: complexType> 

</ xsd: element > 

<xsd:element name -'MonthName " minOccurs ="0"> 

<xsd:simpleType> 

<xsd: restriction base="xsd: string "> 
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<xsd: length value="3"/> 

</xsd: restriction > 

</xsd:simpleType> 

</xsd: element > 

<xsd: element name - 'MessageClassification" type="xsd:anySimpleType"/> 

<xsd:element name - 'MessageFormat " type="xsd: anySimpleType"/ > 
</xsd:sequence> 

<xsd: attribute name ="setid' i type - 'xsd: string" use =" required" fixed =" MSG I D "/> 
</ xsd: complexType> 

</xsd: element > 

<xsd:element name =" Reference" minOccurs ="0"> 

<xsd: complexType> 

<xsd:sequence> 

<xsd:element name ="SerialLetter"> 

<xsd:simpleType> 

<xsd: restriction base="xsd: string "> 

<xsd: length value="l"/> 

</xsd: restriction > 

</xsd:simpleType> 

</ xsd: element > 

<xsd:element name ="TypeOfReferenceRef "> 

<xsd:simpleType> 

<xsd: restriction base-'xsd: string "> 

<xsd: minLength value="2"/> 

<xsd: maxLength value="20"/> 

</xsd: restriction > 

</xsd:simpleType> 

</ xsd: element > 

<xsd:element name ="Originator"> 

<xsd:simpleType> 

<xsd: restriction base="xsd: string "> 

<xsd: minLength value="l"/> 

<xsd: maxLength value="30"/> 

</xsd: restriction > 

</xsd:simpleType> 
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</xsd: element > 

<xsd:element name =" DateAndOrTimeOfReferenceRef" minOccurs ="0"> 
<xsd:simpleType> 

<xsd: restriction base="xsd: string "> 

<xsd: minLength value="6"/> 

<xsd: maxLength value="15"/> 

</xsd: restriction > 

</xsd:simpleType> 

</xsd: element > 

<xsd:element name ="SerialNumberOfReference" minOccurs ="0"> 
<xsd:simpleType> 

<xsd: restriction base="xsd: string "> 

<xsd: minLength value="l"/> 

<xsd: maxLength value="10"/> 

</xsd: restriction > 

</xsd:simpleType> 

</xsd: element > 

<xsd:element name ="SpecialNotation " minOccurs ="0"> 

<xsd:simpleType> 

<xsd: restriction base="xsd: string "> 

<xsd: length value="5"/> 

</xsd: restriction > 

</xsd:simpleType> 

</xsd: element > 

<xsd:element name =" ReferenceFieldGroup"> 

<xsd:complexType> 

<xsd:sequence> 

<xsd: element name ="SicCodeOrFilingNumberRef" minOccurs ="07 > 
</xsd:sequence> 

</ xsd: complexType> 

</xsd: element > 

</xsd:sequence> 

<xsd: attribute name ="setid" type="xsd: string" use="required" fixed ="REF "/> 
</ xsd: complexType> 

</ xsd: element > 
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<xsd:element name ="Amplification " minOccurs ="0"> 

<xsd:complexType> 

<xsd:sequence> 

<xsd:element name -'FreeText" minOccurs ="07 > 

</xsd:sequence> 

<xsd: attribute name ="setid" type="xsd: string" use="required" fixed ="AMPN"/> 
</ xsd: complexType> 

</xsd: element > 

<xsd: element name -'Narrativel nformation" minOccurs ="0"> 
<xsd:complexType> 

<xsd:sequence> 

<xsd: element name -'FreeText" minOccurs ="0"/> 

</xsd:sequence> 

</ xsd: complexType> 

</ xsd: element > 

<xsd:element name ="TypeOfOrder"> 

<xsd:complexType> 

<xsd:sequence> 

<xsd:element name ="TypeOfPlanOrder"> 

<xsd:simpleType> 

<xsd: restriction base="xsd: string "> 

<xsd: minLength value="3"/> 

<xsd: maxLength value="16"/> 

</xsd: restriction > 

</xsd:simpleType> 

</ xsd: element > 

<xsd:element name ="OrderOriginatorAndOrNumber" minOccurs ="0"> 
<xsd:simpleType> 

<xsd: restriction base="xsd: string "> 

<xsd: minLength value="0"/> 

<xsd: maxLength value="59"/> 

</xsd: restriction > 

</xsd:simpleType> 

</ xsd: element > 

</xsd:sequence> 
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<xsd: attribute name ="setid" type="xsd: string" use="required" fixed ="ORDTYP"/> 
</xsd:complexType> 

</xsd: element > 

<xsd:element name -'MapDatal nformation" minOccurs ="0"> 

<xsd:complexType> 

<xsd:sequence> 

<xsd:element name ="MapOrChartSeriesDesignator"> 

<xsd:simpleType> 

<xsd: restriction base-'xsd: string "> 

<xsd: minLength value="3"/> 

<xsd: maxLength value="16"/> 

</ xsd: restriction > 

</xsd:simpleType> 

</ xsd: element > 

<xsd:element name ="MapOrChartSuffixNumber" minOccurs ="0"> 
<xsd:simpleType> 

<xsd: restriction base-'xsd: integer"> 

<xsd:totalDigits value="2"/> 

</xsd: restriction > 

</xsd:simpleType> 

</ xsd: element > 

<xsd: element name - 'MapDatal nformationFieldGroup" minOccurs ="0"> 

<xsd: complexType> 

<xsd:sequence> 

<xsd:element name -'MapOrChartSheetNumber" minOccurs ="0"> 
<xsd:simpleType> 

<xsd: restriction base="xsd: string "> 

<xsd: minLength value="l"/> 

<xsd: maxLength value="14"/> 

</ xsd: restriction > 

</xsd:simpleType> 

</ xsd: element > 

<xsd:element name -'MapOrChartEditionNumber" minOccurs ="0"> 
<xsd:simpleType> 

<xsd: restriction base-'xsd: string "> 
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<xsd: minLength value="l"/> 

<xsd: maxLength value="6"/> 

</xsd: restriction > 

</xsd:simpleType> 

</xsd: element > 

<xsd:element name -'GeodeticDatum" minOccurs ="0"> 

<xsd:simpleType> 

<xsd: restriction base="xsd: string "> 

<xsd: minLength value="2"/> 

<xsd: maxLength value="5"/> 

</xsd: restriction > 

</xsd:simpleType> 

</xsd: element > 

</xsd:sequence> 

</ xsd: complexType> 

</xsd: element > 

</xsd:sequence> 

<xsd: attribute name ="setid" type="xsd: string" use="required" fixed ="MAP"/> 

</ xsd: complexType> 

</ xsd: element > 

<xsd:element name ="TimeZone"> 

<xsd:complexType> 

<xsd: simpleContent > 

<xsd: extension base ="xsd: string "> 

<xsd: attribute name ="setid" type="xsd: string" use="required" fixed ="TI MEZONE "/> 
<xsd: attribute name -'timeZoneZulu" type - 'xsd: string" use="required"/> 

</ xsd: extension> 

</ xsd: simpleContent> 

</ xsd: complexType> 

</ xsd: element > 

<xsd:element name ="OrderReference" minOccurs ="0"> 

<xsd: com pie xTy pe > 

<xsd:sequence> 

<xsd:element name ="TypeOfPlanOrder"> 

<xsd:simpleType> 
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<xsd: restriction base-'xsd: string "> 

<xsd: minLength value="3"/> 

<xsd: maxLength value="16"/> 

</xsd: restriction > 

</xsd:simpleType> 

</xsd: element > 

<xsd:element name ="OrderOriginatorAndOrNumber"> 

<xsd:complexType> 

<xsd:sequence> 

<xsd:element name ="MilitaryCommandAuthority"> 

<xsd:complexType> 

<xsd: simpleContent > 

<xsd: extension base ="xsd: string "> 

<xsd: attribute name ="objectl tern I dN umber" type="xsd: anySimpleType use =" required"/ > 
</ xsd: extension> 

</ xsd: simpleContent> 

</xsd:complexType> 

</ xsd: element > 

<xsd: element name ="TwoCharacterSpaceFiller"/> 

<xsd:element name ="OperationOrderNumber" type="xsd: string "/> 

</xsd:sequence> 

</ xsd: complexType> 

</ xsd: element > 

</xsd:sequence> 

<xsd: attribute name ="setid" type="xsd: string" use="required" fixed ="ORDREF "/> 
</xsd:complexType> 

</ xsd: element > 

<xsd:element name - 'HeadingForSegmentsOfAMessage" minOccurs ="0"> 
<xsd:complexType> 

<xsd:sequence> 

<xsd: element name =" Heading I nformation"> 

<xsd:simpleType> 

<xsd:restriction base- 'xsd: string M > 

<xsd: minLength value="l"/> 

<xsd: maxLength value="61"/> 
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</xsd: restriction > 

</xsd:simpleType> 

</xsd: element > 

</xsd:sequence> 

<xsd: attribute name ="setid" type="xsd: string" use =" required" fixed ="HEADI NG"/ > 

</ xsd: complexType> 

</xsd: element > 

<xsd: element name =" Mi I itary U n itl dentificationAndLocation_information" minOccurs ="0"> 
<xsd:complexType> 

<xsd:sequence> 

<xsd: element name ="ColumnDefinition "/ > 

<xsd: element name - 'MilitaryUnitl dentification And Location I nformationFieldGroup"/> 
</xsd:sequence> 

</ xsd: complexType> 

</ xsd: element > 

<xsd:element name -'GeneralTextl nformation" minOccurs - O' maxOccurs ="unbounded"> 
<xsd:complexType> 

<xsd: complexContent > 

<xsd:extension base="GeneralTextl nformationType > 

<xsd: attribute name - 'name " type="xsd: anySimpleType" use="optional"/> 

</ xsd: extension> 

</ xsd: complexContent > 

</ xsd: complexType> 

</ xsd: element > 

<xsd:element name =" DesignatedHour" minOccurs ="0"> 

<xsd:complexType> 

<xsd:sequence> 

<xsd:element name -'HourName "> 

<xsd:simpleType> 

<xsd: restriction base="xsd: string "> 

<xsd: minLength value="l"/> 

<xsd: maxLength value="8"/> 

</xsd: restriction > 

</xsd:simpleType> 

</ xsd: element > 
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<xsd: element name ="Actionl ndicator"> 

<xsd:simpleType> 

<xsd: restriction base="xsd: string "> 

<xsd: minLength value="3"/> 

<xsd: maxLength value="6"/> 

</ xsd: restriction > 

</xsd:simpleType> 

</ xsd: element > 

<xsd:element name =" DayTimeGroup" minOccurs ="0"> 

<xsd:simpleType> 

<xsd: restriction base-'xsd: string "> 

<xsd: length value="6"/> 

</xsd: restriction > 

</xsd:simpleType> 

</ xsd: element > 

</xsd:sequence> 

<xsd: attribute name-'setid" type="xsd:string" use="required" fixed="HOURIS "/> 
</ xsd: complexType> 

</ xsd: element > 

<xsd: element name ="Annexl nformation" minOccurs =' 0"> 

<xsd: complexType> 

<xsd:sequence> 

<xsd:element name ="AnnexName "> 

<xsd:simpleType> 

<xsd: restriction base="xsd: string "> 

<xsd: minLength value="l"/> 

<xsd: maxLength value="2"/> 

</xsd: restriction > 

</xsd:simpleType> 

</ xsd: element > 

<xsd:element name ="AnnexNumber"> 

<xsd:simpleType> 

<xsd: restriction base- 'xsd: string M > 

<xsd: minLength value="l"/> 

<xsd: maxLength value="20"/> 
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</xsd: restriction > 

</xsd:simpleType> 

</xsd: element > 

</xsd:sequence> 

<xsd: attribute name ="setid" type="xsd: string" use =" required" fixed ="ANN EXES "/> 

</ xsd: complexType> 

</xsd: element > 

<xsd:element name ="AcknowledgeRequirement"> 

<xsd:complexType> 

<xsd:sequence> 

<xsd: element name ="AcknowledgementRequirementl ndicator"> 

<xsd:simpleType> 

<xsd: restriction base-'xsd: string' > 

<xsd: minLength value="2"/> 

<xsd: maxLength value="3"/> 

</xsd: restriction > 

</xsd:simpleType> 

</ xsd: element > 

<xsd:element name ="AcknowledgementRequirementFieldGroup" type ="xsd: string" minOccurs ="0"/ > 
</xsd:sequence> 

<xsd: attribute name ="setid" type="xsd: string" use="optional" fixed ="AKN LDG" /> 

</ xsd: complexType> 

</ xsd: element > 

<xsd:element name =" Remarks" minOccurs ="0"> 

<xsd:complexType> 

<xsd:sequence> 

<xsd:element name="FreeText"/> 

</xsd:sequence> 

</ xsd: complexType> 

</ xsd: element > 

<xsd:element name ="MessageDowngradingOrDeclassification_data" minOccurs ="0"> 

<xsd: complexType> 

<xsd:sequence> 

<xsd:element name ="SourceForClassificationDecl"> 

<xsd:simpleType> 
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<xsd: restriction base="xsd: string "> 

<xsd: minLength value="l"/> 

<xsd: maxLength value="55"/> 

</xsd: restriction > 

</xsd:simpleType> 

</xsd: element > 

<xsd:element name-'ReasonForClassification" minOccurs ="0"> 
<xsd:simpleType> 

<xsd: restriction base- 'xsd: string l! > 

<xsd: length value="3"/> 

</xsd: restriction > 

</xsd:simpleType> 

</xsd: element > 

<xsd:element name ="MessageDowngradingOrDeclassificationDataFieldGroup"> 
<xsd:complexType> 

<xsd:sequence> 

<xsd: element name =" Downgradel nstructionsDateDecl"> 

<xsd:simpleType> 

<xsd: restriction base="xsd:string"> 

<xsd: minLength value="l'7> 

<xsd: maxLength value="38"/> 

</xsd: restriction > 

</xsd:simpleType> 

</xsd: element > 

<xsd:element name =" DowngradingOrDeclassificationExemptionCode"> 
<xsd:simpleType> 

<xsd: restriction base="xsd: string "> 

<xsd: length value="2"/> 

</xsd: restriction > 

</xsd:simpleType> 

</xsd: element > 

</xsd:sequence> 

</ xsd: complexType> 

</xsd: element > 

</xsd:sequence> 
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</ xsd: complexType> 

</xsd: element > 

<!- -THE EXER SET PROVIDES THE DESIGNATED CODE NAME OR NICKNAME, IF THE MESSAGE SUPPORTS AN 
EXERCISE. --> 

<!- -THE OPER SET PROVIDES THE DESIGNATED CODE NAME OR NICKNAME, IF THE MESSAGE SUPPORTS AN 
OPERATI ON. - - > 

<!- -THE MSGID SET PROVIDES THE MESSAGE IDENTIFICATION AND ORI Gl NATOR. -- > 

<!- -THE REF SET PROVIDES BOTH USMTF AND NON-USMTF REFERENCES. .--> 

<!- -THE ORDTYP SET SPECIFIES THE TYPE OF FIVE PARAGRAPH ORDER BEING SENT..--> 

<!- -THE MAP SET PROVIDES THE MAP REFERENCES FOR THE ORDER MESSAGE. --> 

<!- -THE TIMEZONE SET DESIGNATES ZULU TIME AS THE REFERENCE FOR THE ORDER MESSAGE. .--> 

<!- -THE ORDREF SET SPECIFIES THE TYPE AND DESIGNATION (NUMBER OR LETTER) OF THE BASIC ORDER 
ADDRESSED BY THIS MESSAGE.. -> 

<!- -THE HEADING/TASK ORGANIZATION SET INTRODUCES THE SECTION FOR ADDRESSING TASK UNITS --> 

<!- -THE HOURIS SET PROVIDES THE DESIGNATED HOUR FORTHE ORDER. --> 

<!- -THE ANNEXES SET PROVIDES A LISTING FOR ALL APPROPRIATE ANNEXES TO THE ORDER. --> 

<!- -THE AKNLDG SET PROVIDES OPERATOR ACKNOWLEDGEMENT AND NOT COMMUNICATIONS CENTER 
ACKNOWLEDGEMENT.-- > 

<!- -THE DECL SET PROVIDES DECLASSIFICATION OR DOWNGRADING INSTRUCTIONS, IF THE MESSAGE IS 
CLASSIFIED. --> 

</xsd:sequence> 

</ xsd: complexType> 

</ xsd: element > 

<!-- There are normally 5 General Text Information fields, they are SITUATION | MISSION | EXECUTION | ADMIN AND 
LOG | COMMAND AND CONTROL - -> 

<xsd:complexType name -'GeneralTextlnformationType"> 

<xsd: annotation > 

<xsd:documentation >GENTEXT sections of the Order messagec/ xsd:documentation > 

</ xsd: annotation > 

<xsd:sequence> 

<xsd:element name -'GentextTextl ndicator" id- 'EXECUTI ON" minOccurs ="0"> 

<xsd:complexType> 

<xsd: simpleContent > 

<xsd: extension base ="xsd: string "> 

<xsd: attribute name-'contextld" type="xsd: anySimpleType" use="optional"/ > 
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</ xsd: extension> 

</ xsd: simpleContent> 

</ xsd: complexType> 

</ xsd: element > 

<xsd:element name -'FreeText " type="xsd: string" minOccurs ="0"/> 

<xsd: element name ="Cdrsl ntentAndConceptOfOperations" minOccurs ="0"> 
<xsd:complexType> 

<xsd:sequence> 

<xsd:element name =" BattalionCdrlntent"/ > 

<xsd:element name ="EndState"/> 

<xsd: element name ="ConceptOfOperations "/ > 

</xsd:sequence> 

</ xsd: complexType> 

</ xsd: element > 

<xsd:element name="Tasks" minOccurs ="0"> 

<xsd:complexType> 

<xsd:sequence> 

<xsd:element name ="Organization" minOccurs ="0"> 

<xsd: complexType> 

<xsd:sequence> 

<xsd:element name ="MarineExpeditionaryUnit" minOccurs ="0"> 

<xsd:complexType> 

<xsd: sequence> 

<xsd:element name =" BattalionLandingTeam" minOccurs ="0"> 

<xsd:complexType> 

<xsd:sequence> 

<xsd:element name ="Company " minOccurs ="0" maxOccurs ="3"> 

<xsd: complexType> 

<xsd:sequence> 

<xsd: element name -'Platoon " minOccurs ="0" maxOccurs ="3"> 

<xsd: complexType> 

<xsd:sequence> 

<xsd:element name="Squad" minOccurs ="0" maxOccurs ="2"> 

<xsd:complexType> 

<xsd: attribute name - 'objectltemIdNumber" type="xsd: anySimpleType' use =" required"/ > 
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<xsd: attribute name ="objectTypeldNumber" type="xsd: anySimpleType" use=" required"/ > 
<xsd: attribute name - 'name " type-'xsd: anySimpleType use="required"/> 

<xsd: attribute name ="callSign" type="xsd: anySimpleType" use="optional'7 > 

</ xsd: complexType> 

</xsd: element > 

</xsd:sequence> 

<xsd: attribute name -'objecti tem I dN umber" type="xsd: anySimpleType use =" required"/ > 
<xsd: attribute name ="obj ectTy pel dN umber" type="xsd: anySimpleType 11 use="required"/> 
<xsd: attribute name ="name " type-'xsd: anySimpleType" use="required"/> 

<xsd: attribute name ="callSign" type="xsd: anySimpleType" use="optional"/ > 
</xsd:complexType> 

</ xsd: element > 

</xsd:sequence> 

<xsd: attribute name - 'objecti tem I dN umber" type ="xsd: anySimpleType use =" required"/ > 
<xsd: attribute name ="obj ectTy pel dN umber" type="xsd: anySimpleType" use="required"/> 
<xsd: attribute name - 'name "/ > 

<xsd: attribute name ="callSign" type-'xsd: anySimpleType" use="optional"/ > 
</xsd:complexType> 

</ xsd: element > 

</xsd:sequence> 

<xsd: attribute name ="objectl tem I dN umber" type ="xsd: anySimpleType use =" required"/ > 
<xsd: attribute name ="obj ectTy pel dN umber" type="xsd: anySimpleType" use="required"/> 
<xsd: attribute name - 'name "/ > 

</ xsd: complexType> 

</ xsd: element > 

</xsd:sequence> 

<xsd: attribute name ="objectl tem I dN umber" type ="xsd: anySimpleType use="optional"/> 
<xsd: attribute name -'objectTypel dNumber" type- 'xsd: anySimpleType" use- 'optional"/ > 
<xsd: attribute name - 'name " type="xsd: anySimpleType" use="required"/> 

</ xsd: complexType> 

</ xsd: element > 

</xsd:sequence> 

</xsd:complexType> 

</ xsd: element > 

<xsd:element name ="ExecutionTimelineAndMovement " minOccurs ="0"> 
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<xsd:complexType> 

<xsd:sequence> 

<xsd:element name ="l nsertion" maxOccurs ="3"> 

<xsd:complexType> 

<xsd: attributeGroup ref="startTime "/> 

<xsd:attributeGroup ref="location"/> 

<xsd: attribute name ="objectl tern I dN umber" type-'xsd: anySimpleType' use="optional"/> 

<xsd: attribute name -'objectTypel dNumber" type="xsd: anySimpleType" use="optional"/ > 

<xsd: attribute name - 'name " type-'xsd: anySimpleType" use="optional"/> 

<xsd: attribute name ="actionDescription" type ="xsd: anySimpleType" use-'optional"/ > 

<xsd: attribute name - 'actionI dNumber" type="xsd: anySimpleType' use -'optional"/ > 

<xsd: attribute name ="candidateTargetDetaill ndexNumber" type ="xsd: anySimpleType' use="optional"/> 
<xsd: attribute name -'action" type="xsd: anySimpleType" use="optional"/> 

</ xsd: complexType> 

</xsd: element > 

<xsd:element name ="l nfiltration" minOccurs- 0' maxOccurs ="3"> 

<xsd:complexType> 

<xsd: attributeGroup ref="startTime "/> 

<xsd:attributeGroup ref="location"/> 

<xsd: attribute name ="objectl tern I dNumber" type="xsd: anySimpleType' use="optional"/> 

<xsd: attribute name ="objectTypel dNumber" type="xsd: anySimpleType" 1 use="required"/> 

<xsd: attribute name - 'name " type="xsd: anySimpleType" use="optional"/> 

<xsd: attribute name ="actionDescription" type ="xsd:anySimpleType" use-'optional"/ > 

<xsd: attribute name - 'actionI dNumber" type="xsd: anySimpleType' use -'optional"/ > 

<xsd: attribute name ="candidateTargetDetaill ndexN umber" type ="xsd: anySimpleType' use="optional"/> 
<xsd: attribute name -’action" type="xsd: anySimpleType" use="optional"/> 

</xsd:complexType> 

</ xsd: element > 

<xsd:element name ="ActionsAtTheObjective" maxOccurs ="3"> 

<xsd: complexType> 

<xsd: attributeGroup ref="startTime "/> 

<xsd:attributeGroup ref="location"/> 

<xsd: attribute name ="objectl tern I dNumber" type ="xsd: anySimpleType' use-'optional"/ > 

<xsd: attribute name - 'objectTypeldNumber" type- 'xsd: anySimpleType" use-'optional"/ > 

<xsd: attribute name - 'name " type-'xsd: anySimpleType use="optional"/> 
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<xsd: attribute name -'actionDescription" type="xsd: anySimpleType" use-'optional"/ > 

<xsd: attribute name - 'actionI dNumber" type="xsd: anySimpleType 1 use-'optional"/ > 

<xsd: attribute name="candidateTargetDetaill ndexNumber" type ="xsd: anySimpleType 1 use="optional"/> 
<xsd: attribute name ="action" type="xsd: anySimpleType" use="optional"/> 

</ xsd: complexType> 

</xsd: element > 

<xsd:element name-'Exfil" minOccurs ="0" maxOccurs ="3"> 

<xsd:complexType> 

<xsd: attributeGroup ref- 'startTime "/> 

<xsd:attributeGroup ref="location"/> 

<xsd: attribute name -'objectl temI dNumber" type ="xsd: anySimpleType 1 use-'optional"/ > 

<xsd: attribute name ="objectTypel dNumber" type="xsd: anySimpleType" use="optional"/ > 

<xsd: attribute name - 'name " type-'xsd: anySimpleType" use="optional"/> 

<xsd: attribute name ="actionDescription" type="xsd: anySimpleType" use-'optional"/ > 

<xsd: attribute name - 'action I dNumber" type="xsd: anySimpleType 1 use-'optional"/ > 

<xsd: attribute name -'candidateTargetDetaill ndexN umber" type ="xsd: anySimpleType 1 use="optional"/> 
<xsd: attribute name -'action" type="xsd: anySimpleType ' use="optional"/> 

</ xsd: complexType> 

</ xsd: element > 

<xsd: element name -'Extraction" maxOccurs ="3"> 

<xsd: complexType> 

<xsd:attributeGroup ref =" startTime "/> 

<xsd:attributeGroup ref="location"/> 

<xsd: attribute name - 'objectl tem I dNumber" type ="xsd: anySimpleType 1 use-'optional"/ > 

<xsd: attribute name -'objectTypeldNumber" type-'xsd: anySimpleType" use-'optional"/ > 

<xsd: attribute name - 'name " type-'xsd: anySimpleType use="optional"/> 

<xsd: attribute name - 'actionDescription" type="xsd: anySimpleType" use-'optional"/ > 

<xsd: attribute name =" action I dNumber" type-'xsd: anySimpleType use-'optional"/ > 

<xsd: attribute name - 'candidateTargetDetaill ndexN umber" type ="xsd: anySimpleType use-'optional"/ > 
<xsd: attribute name -'action" type="xsd: anySimpleType" use="optional"/> 

</ xsd: complexType> 

</ xsd: element > 

</xsd:sequence> 

</ xsd: complexType> 

</ xsd: element > 
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</xsd:sequence> 

</xsd:complexType> 

</xsd: element > 

<xsd:element name ="Coordinatinglnstructions" minOccurs ="0 "> 

<xsd:complexType> 

<xsd:sequence> 

<xsd:element name-'DDay" minOccurs ="0"> 

<xsd: complexType> 

<xsd: attributeGroup ref="startTime "/> 

</ xsd: complexType> 

</xsd: element > 

<xsd:element name-'HHour" minOccurs ="0"> 

<xsd:complexType> 

<xsd: attributeGroup ref="startTime "/> 

</xsd:complexType> 

</ xsd: element > 

<xsd: element name-'LHour" minOccurs - O' > 

<xsd:complexType> 

<xsd: attributeGroup ref="startTime "/> 

</ xsd: complexType> 

</ xsd: element > 

<xsd:element name -'MissionObjectiveLocation" minOccurs="0"> 

<xsd: complexType> 

<xsd: attribute name - 'name " type-'xsd: anySimpleType" use="optional"/> 

<xsd:attributeGroup ref="location"/> 

<xsd: attribute name ="targetl dNumber" type ="xsd: anySimpleType' use- 'optional"/ > 
</ xsd: complexType> 

</ xsd: element > 

<xsd:element name =" BeachLandingSite" minOccurs ="0"> 

<xsd: complexly pe> 

<xsd: attribute name - 'name " type="xsd: anySimpleType" use="optional"/> 

<xsd:attributeGroup ref="location"/> 

</ xsd: complexType> 

</ xsd: element > 

</xsd:sequence> 
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</ xsd: complexType> 

</xsd: element > 

</xsd:sequence> 

</ xsd: complexType> 

<xsd: attributeGroup name="startTime "> 

<xsd: attribute name ="day" type="xsd: anySimpleType" use="optional"/> 

<xsd: attribute name - 'time" type ="xsd: anySimpleType" use="optional"/> 

<xsd: attribute name -'timeZone" type="xsd: anySimpleType" use="optional"/> 

<xsd: attribute name =" month" type ="xsd: anySimpleType" use="optional"/> 

<xsd: attribute name - 'year" type="xsd: anySimpleType" use="optional"/> 

<xsd: attribute name -'julianDate" type="xsd: anySimpleType" use="optional"/> 

<xsd: attribute name ="startTimel nSecondsPerDay" type="xsd: anySimpleType" use="optional"/ > 
</xsd: attributeGroup> 

<xsd:attributeGroup name="location"> 

<xsd: attributeGroup ref - 'latitudeLongitude"/ > 

<xsd:attributeGroup ref="UTM"/> 

<xsd: attribute name - 'locationI dNumber" type - 'xsd: anySimpleType 1 use - 'optional"/ > 

<xsd: attribute name ="featureLocationl ndexNumber" type="xsd: anySimpleType" use="optional"/> 
</xsd: attributeGroup> 

<xsd:attributeGroup name="latitudel_ongitude"> 

<xsd: attribute name - 'latitude" type="xsd: anySimpleType" use="optional"/> 

<xsd: attribute name - 'longitude" type-'xsd: anySimpleType" use="optional"/> 

</xsd: attributeGroup> 

<xsd:attributeGroup name="UTM"> 

<xsd: attribute name - 'utmGridZoneColumn" type ="xsd: anySimpleType" use="optional"/> 

<xsd: attribute name -'utmGridZoneRow" type-'xsd: anySimpleType" use="optional"/> 

<xsd: attribute name - 'utmlOOOOOMeterSquareColumn " type ="xsd: anySimpleType" use="optional"/> 
<xsd: attribute name ="utmlOOOOOMeterSquareRow" type="xsd: anySimpleType" use-'optional"/ > 
<xsd: attribute name ="utmlOMeterEasting " type="xsd: anySimpleType" use="optional"/ > 

<xsd: attribute name - 'utmlOMeterNorthing" type ="xsd: anySimpleType" use="optional"/> 

<xsd: attribute name ="utmlOOMeterEasting" type="xsd: anySimpleType" use="optional"/> 

<xsd: attribute name ="utmlOOMeterNorthing" type-'xsd: anySimpleType" use-'optional"/ > 

</xsd: attributeGroup> 

<xsd: attribute name - 'name "/ > 

<xsd: attribute name -'objectl tern I d Number"/ > 
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<xsd: attribute name -'objectTypel dNumber"/> 

<xsd: attribute name -’callSign" type-'xsd: anySimpleType"/ > 

<xsd: attribute name ="candidateTargetDetaill ndexNumber" type="xsd: anySimpleType"/ > 

<xsd: attributeGroup name="endTime "> 

<xsd: attribute name ="day" type="xsd: anySimpleType" use="optional"/> 

<xsd: attribute name ="time" type ="xsd: anySimpleType" use="optional"/> 

<xsd: attribute name - 'timeZone" type="xsd: anySimpleType" use="optional"/> 

<xsd: attribute name =" month" type ="xsd: anySimpleType" use="optional"/> 

<xsd: attribute name -'year" type="xsd: anySimpleType" use="optional"/> 

<xsd: attribute name ="julianDate" type="xsd: anySimpleType" use="optional"/> 

<xsd: attribute name - endTimel nSecondsPerDay" type- 'xsd: anySimpleType" use="optional"/> 
</xsd: attributeGroup> 

</xsd: schema > 
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APPENDIX J. XML-MTF OPERATION ORDER USIN G NEW SCHEMA 


A. INTRODUCTION 

This Appendix applies the XML-MTF operation order in Appendix F to the improved schema. Whereas the GENTEXT in the 
original message is lumped together as a single tag, GENTEXT data in this message is extracted, making it useful for visualization. 
This message will continue to evolve until the schema in Appendix I is completed. 

B. OPERATION ORDER 

<?xml version = "1.0" encoding = "UTF-8" ?> 

- cr¬ 
edited with XML Spy v4.0 U beta 3.1 build Aug 27 2001 (http://www.xmlspy.com) by Doug Horner (Naval Postgraduate School) 

-- > 

<?xml-stylesheet type="text/xsl" href="C:\Program Files\Altova\XML Spy Suite\XML2XMLconversion.xsl"?> 

- cOrder xml ns: xsi="http:/ / www.w3.org/ 2001/ XMLSchema-instance" 

xsi: noNamespaceSchemaLocation="C :\ Program Files\ Altova\ XML Spy Suite\ ModOperationOrder.xsd"> 

- cExerciseldentification setid-'EXER" name- 'Amphibious Raid on Camp Pendleton" 

action I dNumber- '9999900000"> 
cExerciseNickname >XML01</ ExerciseNickname > 

<! Exercisel dentification > 

- cMessageldentification setid-'MSGI D"> 

cMessageTextFormatl dentifier>ORDER</ MessageTextFormatl dentifier> 

<Originator>J TF 167 </ Originator> 

cMessageSeriaINumber referencel dl\lumber="5250001">129005 </MessageSerialNumber> 
cMessageClassification >UNCLASSI FI ED</MessageClassification> 
cMessageFormat >USMTF </ MessageFormat > 

</Messagel dentification > 
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<TypeOfOrder setid="ORDTYP"> 

<TypeOfPlanOrder>OPORD</TypeOfPlanOrder> 

<OrderOriginatorAndOrNumber / > 

<TypeOfOrder> 

<TimeZone setid="TI MEZONE" timeZoneZulu="Z" /> 

<OrderReference setid="ORDREF"> 

<TypeOfPlanOrder>OPORD</TypeOfPlanOrder> 

- <OrderOriginatorAndOrNumber> 

<M i I itaryCommand Authority 

objectl teml dl\lumber="555550014">USPACCOM</ Mi I itaryCommand Authority > 
<TwoCharacterSpaceFiller>.. </TwoCharacterSpaceFiller> 
<OperationOrderNumber>A101</OperationOrderNumber> 

</OrderOriginatorAndOrNumber> 

<OrderReference> 

<HeadingForSegmentsOfAMessage setid="HEADI NG"> 

<Headingl nformation>TASK ORGANI ZATI ON</ HeadingI nformation> 

<j FleadingForSegmentsOfAMessage> 

<GeneralTextl nformation > 

<GentextTextl ndicator contextld ="92220001 ">SITUATI ON</GentextTextl ndicator> 

<FreeText >A. GENERAL. REFER TO BASI C ORDER B. ENEMY FORCES. REFER TO BASI C ORDER C. 

FRI ENDLY FORCES. REFER TO BASI C ORDER D. ATTACHMENTS AND DETACHMENTS. ANNEX A 
(TASK ORGANI ZATI ON) </FreeText> 

<GeneralTextl nformation > 

<GeneralTextl nformation > 

<GentextTextl ndicator contextl d ="92220002">MI SSI ON</GentextTextl ndicator> 

<FreeText >AT H-HOUR, BLT 1/ 4 CONDUCTS AN AAAV RAI D ACROSS RED BEACH AND PROCEEDS 
INLAND TO SEIZE ATF OBJ ECTI VE A. ONCE SEIZED, MAI NTAI N SECURITY OF OBJ ECTI VE UNTI L 
RELI EVED BY TF APACHE. </FreeText > 

</GeneralTextl nformation > 

<GeneralTextl nformation > 

<GentextTextl ndicator contextl d ="92220003">EXECUTI ON</ GentextTextl ndicator> 

<FreeText / > 

- <CdrslntentAndConceptOfOperations> 
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<Batta I ionCd rl ntent>l. BATTALION COMMANDERS INTENT. CURRENTLY THERE IS MINIMAL 
THREAT I N OUR ZONE. HOWEVER, MY CONCERN LI ES IN THE FACT THAT Cl VI LI AN 
REACTI ON I S UNCERTAI N AND THERE ARE GREAT NUMBERS OF THEM NEARBY. AS WE ARE 
DEALING WITH A Cl VI LI AN GROUP, I SEE THEIR VULNERABI LITY AS RESPONSIVENESS AND 
LACK OF TRAINING. I INTEND TO EXPLOIT THIS BY LANDING EARLY IN THE MORNING AND 
MOVI NG TO THE OBJ ECTI VE QUI CKLY BEFORE THE GENERAL POPULACE I S 
AWAKE. </ BattalionCdrl ntent > 

<EndState>2. ENDSTATE. I SEE OUR ENDSTATE AS ATF OBJ ECTI VE A SECURED AND I N 
CONTROL OF CTF 175. </EndState> 

<ConceptOfOperations>3. CONCEPT OF OPERATIONS. AT H-HOUR, BLT 1/ 4 CONDUCTS AN 
AMPHI Bl OUS RAI D TO SEI ZE ATF OBJ ECTI VE A. THREE REI NFORCED PLATOONS FROM 
COMPANY A Wl LL CONDUCT AN AAAV ASSAULT ACROSS RED BEACH AND PROCEED I NLAND 
VI A PREDETERMI NED ROUTE TO SEI ZE ATF OBJ ECTI VE A. COMPANY A Wl LL SECURE THE 
OBJ ECTI VE AND REMAI N UNTI L RELI EVED BY TF APACHE. COMPANY B I S THE RESERVE. 
COMPANY A I S THE MAI N EFFORT AND Wl LL HAVE PRI ORITY OF FI RES FOR THE DU RATI ON 
OF THE OPERATI ON. </ ConceptOfOperations> 

</Cdrsl ntentAndConceptOfOperations> 

<Tasks > 

- <Organization> 

- <MarineExpeditionaryUnit name="15TH MEU" objectltemldNumber="555550001" 
objectTypel dNumber="777770001 "> 

- <BattalionLandingTeam name-'BLTl/ 4" objectltemldNumber="555550002" 
objectTypel dl\lumber="7 77 770002 "> 

- <Company name="l NFANTRY CO" objectltemldNumber="555550003" 

objectTypel dl\lumber="7 77 770003 "> 

<Platoon name ="1ST PLT(REI N)" objectltemldNumber="555550004" 
objectTypel dNumber="777770004" /> 

<Platoon name =' 2ND PLT(REIN)" objectltemldl\lumber="555550005" 
objectTypeldl\lumber="7 77770004" /> 

<Platoon name="3RD PLT(REIN)" objectltemldl\lumber-'555550006" 
objectTypel dl\l urn ber="7 77 770004" /> 

</Company > 

- <Company name =" AAAV CO" objectltemldNumber="555550007" 

objectTypel dNumber="777770003 "> 
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<Platoon name="AAAVl" objectltemldNumber="555550008" 
objectTypel dNumber="777770004" /> 

<Platoon name="AAAV2" objectltemldNumber="555550009" 
objectTypel dNumber="777770004" /> 

<Platoon name="AAAV3" objectltemldNumber="555550010" 
objectTypeldNumber=' 777770004 " /> 

</Company > 

</ BattalionLandingTeam> 

<7 MarineExpeditionaryUnit > 

</Organization> 

<ExecutionTimelineAndMovement > 


insertion name="Primary Insertion Point" objectltemldNumber="555550010" 

objectTypeldNum ber="7 77770010" latitude="N33 11.00" longitude="W117 35.00 day="01" 
time ="1500" timeZone="Z" month="J AN" year="2001" julianDate="36519 " 
startTimel nSecondsPerDay- 1 54000" location I dNumber="888800 01" 

featureLocationl ndexNumber="111110001" actionDescription =" I nsert AAAV Company from 
the LHD" actionl dNumber="999990001 candidateTargetDetaill ndexNumber="1000001" 
action ="l NSERT" /> 


infiltration name ="Primary I nfil Route" objectltemldNumber="555550011" 

objectTypeldl\lurn ber="7 77770011 " latitude="N33 14.9" longitude="W117 25.7" day="01" 
time ="1800" timeZone="Z" month="J AN" year="2001" julianDate="36519" 
startTimel nSecondsPerDay ="54000" location I dN umber- 88880002" 

featureLocationl ndexNumber="111110002" actionDescription ="Secure the BLS, proceed to 
the AF " actionl dNu mber="999990002" candidateTargetDetaill ndexN umber-' 1000002" 
action =" IN FI LT" /> 

<ActionsAtTheObjective name - 'Camp Pendleton Airfield" objectltemldNumber="555550012" 
objectTypel dNu mber="7777700012" latitude="N33 17.88" longitude="W117 21.44" 
day ="01" time="2100" timeZone="Z" month="J AN" year="2001" julianDate="36519" 
startTimel nSecondsPerDay ="54000" location I dN umber- 88880003 " 

featureLocationl ndexNumber="111110003" actionDescription-'Secure Camp Pendleton AF " 
actionl dNumber=' 999990003" candidateTargetDetaill ndexNumber=" 1000003" 


action ="SECURE" /> 

<Exfil name="Primary Exfil Route" objectlteml dNumber="555550013" 

objectTypel dNu mber="777770013" latitude="N33 17.88" longitude="W117 21.44" day="02" 
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time ="0300" timeZone="Z" month="J AN" year="2001" julianDate="36519" 
startTimel nSecondsPerDay ="54000' location I dl\lumber="88880004" 

featureLocationl ndexNumber="111110004" actionDescription =" Return from the Airfield to 
the LHD" actionl dl\lumber="999990004" candidateTargetDetaill ndexNumber="1000004" 
action ="EXFILT" /> 

Extraction name ="Primary Extraction Point" objectltemldNumber="555550014" 

objectTypel dl\lumber="777770014" latitude="N33 17.88" longitude="W117 21.44" day="02" 
time ="0700" timeZone="Z" month="J AN" year="2001" julianDate="36519" 
startTimel nSecondsPerDay ="54000" location I dNumber="88880005" 

featureLocationl ndexNumber="111110005" actionDescription ="Extract AAAV Company and 
return to LHD" actionl dNumber="999990005 " candidateTargetDetaill ndexNumber="1000005" 
action ="EXTRCT" /> 

</ExecutionTimelineAndMovement > 

</Tasks> 

- <Coordinatinglnstructions> 

<DDay day="01" month="J AN" year="2001" /> 

<HHour time ="1500" timeZone="Z" /> 

<LHour time ="1800" timeZone="Z" /> 

<MissionObjectiveLocation name="APE Al RFI ELD (CAMP PENDLETON)" latitude=" N33 17.88" 
longitude="W117 21.44" targetl dl\lumber="6566" /> 

<BeachLandingSite name="Beach Landing Site" latitude="N33 14.9" longitude="W117 25.7" /> 

<! Coordinating! nstructions> 

<GeneralTextl nformation> 

<GeneralTextl nformation > 

<GentextTextlndicator contextld="92220004">ADMI N AND LOG</GentextTextl ndicator> 

<FreeText >REFER TO BASIC ORDERc/FreeText > 

<GeneralTextl nformation > 

<GeneralTextl nformation > 

<GentextTextl ndicator contextld="92220005">COMMAND AND CONTROLc/ GentextTextl ndicator> 
<FreeText >REFER TO OPTASK COMMSc/FreeText > 

</GeneralTextl nformation > 

<AcknowledgeRequirement > 

<AcknowledgementRequirementl ndicator>YES</AcknowledgementRequirementl ndicator> 
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</AcknowledgeRequirement > 
</Order> 
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APPENDIX K. GENERIC HUB SCHEMA 


A. INTRODUCTION 

The Generic Hub (GH) XML schema defines semantic tags that attempt to embrace all possible elements incorporated in the 
database. This schema is robust in that it works for any document or order that may utilize the element tags, not just operation orders. 
This schema is needed in order to create documents that are compliant and interoperable with the GH database. Franciso Loaiza and 
Eugene Simaitis from the Institute for Defense Analysis created this schema. As this order is in excess of 160 pages, it is not included 
it its entirety. Sufficient tags are depicted order to convey enough information to obtain a reasonable appreciation of its contents. 

B. GENERIC HUB SCHEM A 

<?xml version = "l,0" encoding = "UTF-8" ?> 

- cr¬ 
edited with XML Spy v4.0 U beta 3 build Aug 24 2001 (http://www.xmlspy.com) by FRANCISCO L LOAIZA (SED) 

-- > 

- <!-- 

W3C Schema generated by XML Spy v4.0 U beta 3 build Aug 24 2001 (http://www.xmlspy.com) 

-- > 

- <xsd:schema xmlns:xsd="http:/ / www.w3.org/ 2001/ XMLSchema" elementFormDefault ="qualified"> 

- <xsd:element name ="AbsolutePoint"> 

- <xsd:complexType> 

- <xsd:sequence> 

cxsd:element ref="AbsolutePoint.longitudeCoordinate" /> 

<xsd:element ref =' AbsolutePoint.latitudeCoordinate /> 
cxsd:element ref= M AbsolutePoint.elevationCategoryCode" /> 

cxsd:element ref= M AbsolutePoint.id" /> 


145 


<xsd:element ref ="updateSequenceNumber minOccurs ="0" /> 
<xsd:element ref="ownerl d" minOccurs ="0" /> 

</ xsd: sequence> 

<J xsd:complexType> 

</ xsd: element > 

<xsd:element name ="AbsolutePoint.elevationCategoryCode"> 

- <xsd:simpleType> 

- <xsd: restriction base="xsd:string"> 

<xsd:enumeration value="EAP" /> 

<xsd:enumeration value="LOC" /> 

<xsd:enumeration value="NOS" /> 

<xsd:enumeration value="SEA" /> 

<xsd:enumeration value = "" /> 

</xsd: restriction > 

</xsd:simpleType> 

</ xsd: element > 

<xsd:element name ="AbsolutePoint.id" type="xsd:long" /> 

<xsd:element name =" AbsolutePoint.latitudeCoordinate type="xsd:decimal" /> 
<xsd:element name =" AbsolutePoint.longitudeCoordinate type="xsd:decimal" /> 

<xsd:element name ="AbsolutePointTable "> 

- <xsd:complexType> 

- <xsd:sequence> 

<xsd:element ref="AbsolutePoint" maxOccurs -'unbounded" /> 

</xsd: sequence> 

</xsd:complexType> 

<! xsd: element > 

<xsd:element name ="Action"> 

- <xsd:complexType> 

- <xsd:sequence> 

<xsd:element ref= M Action.id" /> 

<xsd:element ref ="Action.name" /> 

<xsd:element ref= M Action.categoryCode" /> 

<xsd:element ref ="updateSequenceNumber minOccurs ="0" /> 
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<xsd:element ref="ownerl d" minOccurs ="0" /> 

</ xsd: sequence> 

<J xsd:complexType> 

</ xsd: element > 

<xsd:element name -'Action.categoryCode"> 

- <xsd:simpleType> 

- <xsd: restriction base="xsd:string"> 

<xsd:enumeration value="ACTEV" /> 

<xsd:enumeration value-' ACTTA" /> 

<xsd:enumeration value = "" /> 

</xsd: restriction > 

<7xsd:simpleType> 

<! xsd: element > 

<xsd:element name ="Action.id" type="xsd:long" /> 

<xsd:element name -'Action.name" type="xsd:string" /> 

<xsd:element name ="ActionAircraftEmployment"> 

- <xsd:complexType> 

- <xsd:sequence> 

<xsd:element ref ="ActionAircraftEmployment.terminalAttackDirectionAngle " /> 

<xsd:element ref ="ActionAircraftEmployment.inflightReportRequirementl ndicatorCode" /> 
<xsd:element ref ="ActionAircraftEmployment.egressDirectionAngle " /> 

<xsd:element ref ="ActionAircraftEmployment.approachOffsetCode /> 

<xsd:element ref ="ActionResource.index" /> 

<xsd:element ref="Action.id" /> 

<xsd:element ref ="updateSequenceNumber minOccurs ="0" /> 

<xsd:element ref="ownerl d" minOccurs ="0" /> 

</xsd: sequence> 

</ xsd:complexType> 

<! xsd: element > 

<xsd:element name ="ActionAircraftEmployment.approachOffsetCode"> 

- <xsd:simpleType> 

- <! —break in schema. - - > 

<xsd:element name ="ActionEffect.descriptionCode"> 
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- <xsd:simpleType> 

- <xsd: restriction base="xsd:string"> 

<xsd:enumeration value="BURN" /> 

<xsd:enumeration value="CAPTUR" /> 

<xsd:enumeration value="CONS" /> 

<xsd:enumeration value="DEST" /> 

<xsd:enumeration value="FKI L" /> 

<xsd:enumeration value="FLIG" /> 

<xsd:enumeration value="l DNT" /> 

<xsd:enumeration value="l LLUMN" /> 

<xsd:enumeration value="KI LL" /> 

- <! —break in schema.- - > 

<xsd:element name ="ActionEvent.subcategoryCode"> 

- <xsd:simpleType> 

- <xsd: restriction base="xsd:string"> 

- <! —break in schema, following actions are not sequential or all- inclusive 

<xsd:enumeration value = "ATTACK" / > 

<xsd:enumeration value="DEFEAT" / > 

<xsd: enumeration value = " DEFEND" / > 

<xsd:enumeration value = " DEFLCT" / > 

<xsd:enumeration value = " DELAY" / > 

<xsd: enumeration value = "DEMO" / > 

<xsd:enumeration value = "DENY" / > 

<xsd:enumeration value = "DEPLOY"/ > 

<xsd:enumeration value-'SECURE " /> 

<xsd:enumeration value = "" /> 

<7 xsd: restriction > 

</xsd:simpleType> 

</ xsd: element > 

<! —break in schema. - - > 

<xsd: element name - 'ActionObjectivel tem "> 

- <xsd:complexType> 

- <xsd:sequence> 


- - > 
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<xsd:element ref ="ActionObjectiveltern.categoryCode 1 /> 

<xsd:element ref -'ActionObjective.index" /> 

<xsd:element ref=Action.id" /> 

<xsd:element ref="Objectltern.id" /> 

<xsd:element ref ="CandidateTargetList.id ' /> 

<xsd:element ref - 'CandidateTargetDetail. index" /> 

<xsd:element ref ="updateSequenceNumber" minOccurs ="0" /> 
<xsd:element ref="ownerl d" minOccurs ="0" /> 

</xsd: sequence> 

<xsd:complexType> 

</ xsd: element > 

<! —break in schema - - > 

<xsd:element name =' ActionResource"> 

- <xsd:complexType> 

- <xsd:sequence> 

<xsd:element ref ='ActionResource.index" /> 

<xsd:element ref- ActionResource.qualifierCode" /> 
<xsd:element ref ='ActionResource.criticalityl ndicatorCode" /> 
<xsd:element ref = M ActionResource.categoryCode" /> 

<xsd:element ref="Action.id" /> 

<xsd:element ref ='AuthorisingOrganisation.id " /> 

<xsd:element ref ="updateSequenceNumber" minOccurs ="0" /> 
<xsd:element ref="ownerl d" minOccurs ="0" /> 

</ xsd: sequence> 

</xsd:complexType> 

</ xsd: element > 

<xsd:element name ="ActionResource.categoryCode"> 

- <xsd:simpleType> 

- <xsd: restriction base="xsd:string"> 

<xsd:enumeration value="RI" /> 

<xsd:enumeration value="RT" /> 

<xsd:enumeration value = "" /> 

</xsd: restriction > 
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</xsd:simpleType> 

</xsd: element > 

- <! —break in schema. - - > 

</xsd: element > 

<xsd:element name -'ActionTask.estimatedDuration" type="xsd:decimal" /> 

<xsd:element name ="ActionTask.id" type="xsd:long" /> 

<xsd:element name =' ActionTask.maximumDuration" type="xsd:decimal" /> 
<xsd:element name =' ActionTask.minimumDuration " type="xsd:decimal" /> 
<xsd:element name - 'ActionTask.plannedEndDate" type="xsd:int" /> 
<xsd:element name -'ActionTask.plannedEndTime" type="xsd:int" /> 
<xsd:element name -'ActionTask.plannedStartDate" type="xsd:int" /> 
<xsd:element name -'ActionTask.plannedStartTime" type="xsd:int" /> 

- <xsd:element name ="ActionTask.priorityCode"> 

- <xsd:simpleType> 

- <xsd: restriction base="xsd:string"> 

<xsd:enumeration value="l" /> 

<xsd:enumeration value="2" /> 

<xsd:enumeration value="3" /> 

<xsd:enumeration value="4" /> 

<xsd:enumeration value="5" /> 

<xsd:enumeration value = "" /> 

<! xsd: restriction > 

<yxsd:simpleType> 

</ xsd: element > 

- <xsd:element name ="ActionTask.startPrecisionCode"> 

- <xsd:simpleType> 

- <xsd: restriction base="xsd:string"> 

<xsd:enumeration value="DAY" /> 

<xsd:enumeration value="HR" /> 

<xsd:enumeration value="MI N" /> 

<xsd:enumeration value="MON" /> 

<xsd:enumeration value="NKN" /> 

<xsd:enumeration value="SEC" /> 
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<xsd:enumeration value="WEK" /> 

<xsd:enumeration value="YEA" /> 

<xsd:enumeration value- 1 " /> 

</ xsd: restriction > 

<xsd:simpleType> 

- <! —break in schema. - - > 

<xsd:element name - 'CandidateTargetList"> 

- <xsd:complexType> 

- <xsd:sequence> 

<xsd:element ref ="CandidateTargetList.id 1 /> 

<xsd:element ref ="CandidateTargetList.name" /> 

<xsd:element ref ="ReportingData.id" /> 

<xsd:element ref ="updateSequenceNumber" minOccurs ="0" /> 

<xsd:element ref="ownerl d" minOccurs ="0" /> 

</xsd: sequence> 

</ xsd:complexType> 

<7 xsd: element 

- <! —break in schema - - > 

<xsd:element name ="ConsumableMaterielType"> 

- <xsd:complexType> 

- <xsd:sequence> 

<xsd:element ref- 'ConsumableMaterielType.perishabilityl ndicatorCode" /> 
<xsd:element ref ="ConsumableMaterielType.issuingWeightQuantity " /> 
<xsd: element ref ="ConsumableMaterielType. issuing Width Dimension" /> 

<xsd: element 
<! —break in schema - - > 

<xsd:element name ="ConsumableMaterielType.categoryCode"> 

- <xsd:simpleType> 

- <xsd: restriction base="xsd:string"> 

<xsd:enumeration value="AMM" /> 

<xsd:enumeration value="CLO" /> 

<xsd:enumeration value="CON" /> 
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<xsd:enumeration value="FOO" /> 

<xsd:enumeration value="MED" /> 

- <! —break in schema. - - > 

- <xsd:element name ="Convoy"> 

- <xsd:complexType> 

- <xsd:sequence> 

<xsd:element ref="Convoy.packetSizeQuantity" /> 

<xsd:element ref ="Convoy.packetGapDimension /> 

<xsd:element ref-'Convoy.nightVehicleGapDimension 1 ' /> 

<xsd:element ref="Convoy.nightSpeedRate" /> 

<xsd:element ref="Convoy.haltDuration" /> 

<xsd: element ref -'Convoy.dayVehicleGapDimension" /> 

<xsd:element ref="Convoy.daySpeedRate" /> 

<xsd:element ref- 'Convoy.id" /> 

<xsd:element ref- 'updateSequenceNumber" minOccurs ="0" /> 

<xsd:element ref="ownerl d" minOccurs ="0" /> 

</ xsd: sequence> 

</xsd:complexType> 

<! xsd: element > 

- <! —break in schema. - - > 

</ xsd: element > 

<xsd:element name -'EquipmentType.id" type="xsd:long" /> 

<xsd:element name ="EquipmentType.loadedWeightQuantity" type="xsd:decimal" /> 
<xsd:element name =' EquipmentType.maximumHeightDimension " type="xsd:decimai" /> 
<xsd:element name ="EquipmentType.maximumLengthDimension" type="xsd:decimal" /> 
<xsd:element name =' EquipmentType.maximumWidthDimension" type="xsd:decimal" /> 

- <xsd:element 

- <! —break in schema. - - > 

- <xsd:element name ="FacilityStatus.operationalStatusQualifierCode"> 

- <xsd:simpleType> 

- <xsd: restriction base="xsd:string"> 

<xsd:enumeration value="DENY" /> 


152 







<xsd:enumeration value-'DESTR" /> 

<xsd:enumeration value-'HVYDAM" /> 

<xsd:enumeration value-'LGTDAM" /> 

<xsd:enumeration value="LST" /> 

<xsd:enumeration value="LVR" /> 

<xsd:enumeration value-'MODDAM" /> 

<xsd:enumeration value="NKN" /> 

<xsd:enumeration value-'UNCNST" /> 

<xsd:enumeration value = "" /> 

</xsd: restriction > 

</xsd:simpleType> 

- <! —break in schema.- - > 

<xsd:element name ="GeographicFeatureStatus.surfaceConditionCode"> 

- <xsd:simpleType> 

- <xsd: restriction base="xsd:string"> 

<xsd:enumeration value="DUST" /> 

<xsd:enumeration value="FLODNG" /> 

<xsd:enumeration value-'GRASS" /> 

<xsd:enumeration value="ICE" /> 

<xsd:enumeration value="MARSH" /> 

<xsd:enumeration value="NOS" /> 

<xsd:enumeration value="SAND" /> 

<xsd:enumeration value-'SCRUB" /> 

<xsd:enumeration value-'SNOW" /> 

<xsd:enumeration value = "" /> 

</ xsd: restriction > 

</xsd:simpleType> 

- <! —break in schema. - - > 

<xsd:element name - 'Light.categoryCode"> 

- <xsd:simpleType> 

- <xsd: restriction base="xsd:string"> 

<xsd:enumeration value="CI VI L" /> 
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<xsd:enumeration value-'DARK" /> 

<xsd:enumeration value="DAY" /> 

<xsd:enumeration value-'MOON" /> 

<xsd:enumeration value-' NAUTIC " /> 

<xsd:enumeration value- 1 " /> 

</xsd: restriction > 

- <! —break in schema.- - > 

<xsd:element name ="Location"> 

- <xsd:complexType> 

- <xsd:sequence> 

<xsd:element ref="Location.id" /> 

<xsd:element ref="Location.categoryCode" /> 

<xsd:element ref="updateSequenceNumber" minOccurs ="0" /> 
<xsd:element ref="ownerl d" minOccurs ="0" /> 

</xsd: sequence> 

</ xsd:complexType> 

<7xsd: element > 

- <! —break in schema. - - > 

<xsd:element name ="MaterielType"> 

- <xsd:complexType> 

- <xsd:sequence> 

<xsd:element ref="MaterielType.stockNumberText" /> 
<xsd:element ref="MaterielType.categoryCode" /> 

<xsd:element ref="MaterielType.id" /> 

<xsd:element ref ="updateSequenceNumber minOccurs ="0" /> 
<xsd:element ref="ownerl d" minOccurs ="0" /> 

</xsd: sequence> 

<J xsd:complexType> 

- <! —break in schema. - - > 

<xsd:element name ="Minefield"> 

- <xsd:complexType> 

- <xsd:sequence> 
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<xsd: element ref ^Minefield.purposeCode /> 

<xsd:element ref="Minefield.persistenceCode" /> 

<xsd:element ref="Minefield.patternCode" /> 

<xsd:element ref ="Minefield.mineSpacingDimension" /> 

<xsd:element ref="Minefield.id" / > 

<xsd:element ref ="updateSequenceNumber minOccurs ="0" /> 
<xsd:element ref="ownerl d" minOccurs ="0" /> 

</ xsd: sequence> 

</xsd:complexType> 

- <! —break in schema - - > 

<xsd:element name -'Objectl tem "> 

- <xsd:complexType> 

- <xsd:sequence> 

<xsd:element ref="Objectltem.id" /> 

<xsd:element ref ="Objectltem.name" /> 

<xsd:element ref="Objectltem.categoryCode" /> 

<xsd:element ref ="updateSequenceNumber minOccurs ="0" /> 
<xsd:element ref="ownerl d" minOccurs ="0" /> 

<J xsd: sequence> 

</xsd:complexType> 

<y xsd: element > 

<xsd:element name - 'Objectl tem.categoryCode"> 

- <xsd:simpleType> 

- <xsd: restriction base="xsd:string"> 

<xsd:enumeration value="FA" /> 

<xsd:enumeration value="FE" /> 

<xsd:enumeration value="MA" /> 

<xsd:enumeration value="OR" /> 

<xsd:enumeration value="PE" /> 

<xsd:enumeration value = "" /> 

</xsd: restriction > 

</xsd:simpleType> 
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- <! —break in schema. - - > 

<xsd:element name ="OrganisationOrganisationAssociation.subcategoryCode"> 

- <xsd:simpleType> 

- <xsd: restriction base="xsd:string"> 

<xsd:enumeration value-'ADMI N" /> 

<xsd:enumeration value-'ALTFOR" /> 

<xsd:enumeration value="ASGND" /> 

<xsd:enumeration value- 1 ATPRCL" /> 

<xsd:enumeration value=" ATTACH " /> 

<xsd:enumeration value-'CAPT" /> 

<xsd:enumeration value-'COMD" /> 

<xsd:enumeration value="DI RSUP" /> 

<xsd:enumeration value-'FORCE" /> 

- <! —break in schema. - - > 

<xsd:element name ="Person"> 

- <xsd:complexType> 

- <xsd:sequence> 

<xsd:element ref="Person.religionCode" /> 

<xsd:element ref="Person.genderCode" /> 

<xsd:element ref="Person.bloodTypeCode" /> 

<xsd:element ref="Person.birthDate" /> 

<xsd: element ref="Person.alternatel dentificationText" /> 

<xsd:element ref="Person.id" /> 

<xsd:element ref="updateSequenceNumber" minOccurs ="0" / > 
<xsd:element ref="ownerl d" minOccurs ="0" /> 

</xsd: sequence> 

</xsd:complexType> 

<7xsd: element > 

<xsd:element name ="Person.alternatel dentificationText" type="xsd:string" /> 

<xsd:element name ="Person.birthDate" type="xsd:int" /> 

<xsd:element name - 'Person.bloodTypeCode"> 

- <xsd:simpleType> 
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- <xsd: restriction base="xsd:string"> 

<xsd:enumeration value="A+" /> 

<xsd:enumeration value="A-" /> 

<xsd:enumeration value="AB + " /> 

<xsd:enumeration value="AB-" /> 

<xsd:enumeration value="B + " /> 

<xsd:enumeration value="B-" /> 

<xsd:enumeration value-' NKN" /> 

<xsd:enumeration value="0 + " /> 

<xsd:enumeration value="0-" /> 

<xsd:enumeration value = "" /> 

</ xsd: restriction > 

</xsd:simpleType> 

</xsd: element > 

<xsd:element name ="Person.genderCode"> 

- <xsd:simpleType> 

- <xsd: restriction base="xsd:string"> 

<xsd:enumeration value="F" /> 

<xsd:enumeration value="M" /> 

<xsd:enumeration value-' NKN" /> 

<xsd:enumeration value = "" /> 

</xsd: restriction > 

</xsd:simpleType> 

</xsd: element > 

<xsd:element name ="Person.id" type="xsd:long" / 
<xsd:element name ="Person.religionCode"> 

- <xsd:simpleType> 

- <xsd: restriction base="xsd:string"> 

<xsd:enumeration value="ATH" /> 

<xsd:enumeration value="BUD" /> 

<xsd: enumeration value="GRC " /> 

<xsd:enumeration value="HIN" /> 

<xsd: enumeration value="J UD" / > 




<xsd:enumeration value-'MUSLI M" /> 

<xsd:enumeration value-' NKN" /> 

<xsd:enumeration value="NON" /> 

<xsd:enumeration value="ORT" /> 

<xsd:enumeration value="PRO" /> 

<xsd:enumeration value="ROM" /> 

<xsd:enumeration value = "" /> 

<! xsd: restriction > 

</xsd:simpleType> 

<! xsd: element > 

- <! —break in schema. - - > 

<xsd:element name - 'Precipitation.categoryCode"> 

- <xsd:simpleType> 

- <xsd: restriction base="xsd:string"> 

<xsd:enumeration value-'DRZLE" /> 

<xsd:enumeration value-'FDRZLE" /> 

<xsd:enumeration value="FRAI N" /> 

<xsd:enumeration value-'HAI L" /> 

<xsd:enumeration value-'ICECRY " /> 

<xsd:enumeration value-' I CEPLT" /> 

<xsd:enumeration value-' NPR" /> 

<xsd: enumeration value=" RAI N" / > 

<xsd:enumeration value-' RAI NSR" /> 

<xsd:enumeration value-'SLEET" /> 

<xsd:enumeration value-'SNOW" /> 

<xsd:enumeration value="SNWGRN" /> 

<xsd:enumeration value-'SNWSHR" /> 

<xsd:enumeration value = "" /> 

</xsd: restriction > 

</xsd:simpleType> 

- <! —break in schema.- - > 

<xsd: element name ="Reference.transmittalTypeCode"> 
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- <xsd:simpleType> 

- <xsd: restriction base="xsd:string"> 

<xsd:enumeration value-'COUMSG" /> 

<xsd:enumeration value-'EMLMSG" /> 

<xsd:enumeration value="FAXMSG" /> 

<xsd:enumeration value-' NKN" /> 

<xsd:enumeration value="NOS" /> 

<xsd:enumeration value-'PHNMSG" /> 

<xsd:enumeration value-' RADMSG" /> 

<xsd:enumeration value="SFXMSG" /> 

<xsd:enumeration value-'TELEX" /> 

<xsd:enumeration value = "" /> 

</xsd: restriction > 

</xsd:simpleType 

- <! —break in schema.- - > 

<xsd:element name =" Route.mobilityCode"> 

- <xsd:simpleType> 

- <xsd: restriction base="xsd:string"> 

<xsd:enumeration value-'FOOT" /> 

<xsd:enumeration value="NKN" /> 

<xsd:enumeration value-'TRACK" /> 

<xsd:enumeration value-'WHEEL" /> 

<xsd:enumeration value="WHTR" /> 

<xsd:enumeration value = "" /> 

</xsd: restriction > 

</xsd:simpleType> 

<7xsd: element > 

- <! —break in schema. - - > 

<xsd:element name ="RuleOfEngagement"> 

- <xsd:complexType> 

- <xsd:sequence> 

<xsd:element ref ="RuleOfEngagement.id " / 






<xsd:element ref ="RuleOfEngagement.descriptionText 1 /> 
<xsd:element ref ="RuleOfEngagement.name" /> 

<xsd:element ref="updateSequenceNumber" minOccurs ="0" /> 
<xsd:element ref="ownerl d" minOccurs ="0" /> 

</xsd:sequence> 

</xsd:complexType> 

- <! —break in schema.- - > 

<xsd:element name ="SurveillanceCapability.categoryCode"> 

- <xsd:simpleType> 

- <xsd: restriction base="xsd:string"> 

<xsd:enumeration value="COM" /> 

<xsd:enumeration value="ELC" /> 

<xsd:enumeration value-'HUM" /> 

<xsd:enumeration value="IMG" /> 

<xsd:enumeration value-' NKN" /> 

<xsd:enumeration value="NOS" /> 

<xsd:enumeration value="SIG" /> 

<xsd:enumeration value = "" /> 

</xsd: restriction > 

</xsd:simpleType> 

</xsd: element > 

- <! —break in schema.- - > 

<xsd:element name ="TargetMarking"> 

- <xsd:complexType> 

- <xsd:sequence> 

<xsd:element ref="TargetMarking.startTime" /> 

<xsd:element ref="TargetMarking.startDate" /> 

<xsd:element ref="TargetMarking.methodCode" /> 

<xsd:element ref ="ActionObjective.index" /> 

<xsd:element ref="Action.id" /> 

<xsd:element ref="UsingOrganisation.id" /> 

<xsd:element ref ="updateSequenceNumber minOccurs ="0" /> 


160 






<xsd:element ref="ownerl d" minOccurs ="0" /> 

</ xsd: sequence> 

<J xsd:complexType> 

</ xsd: element > 

<! —break in schema.- - > 

<xsd:element name ="UnitType"> 

- <xsd:complexType> 

- <xsd:sequence> 

<xsd:element ref="UnitType.sizeCode" /> 

<xsd:element ref="UnitType.serviceCode" /> 

<xsd:element ref="UnitType.mobilityCode" /> 

<xsd:element ref="UnitType.categoryCode" /> 

<xsd:element ref="UnitType.id" /> 

<xsd:element ref ="PrincipalEquipmentType.id 1 /> 

<xsd:element ref ="updateSequenceNumber" minOccurs ="0" /> 
<xsd:element ref="ownerl d" minOccurs ="0" /> 

<J xsd: sequence> 

</xsd:complexType> 

<! —break in schema. - - > 

<xsd:element name - 'Visibility.categoryCode"> 

- <xsd:simpleType> 

- <xsd: restriction base="xsd:string"> 

<xsd:enumeration value="DSTSND" /> 

<xsd:enumeration value="BLWSNW" /> 

<xsd:enumeration value="DSTDVL" /> 

<xsd:enumeration value="DSTSTR" /> 

<xsd:enumeration value="FOG" /> 

<xsd:enumeration value="FRZFOG" /> 

<xsd:enumeration value-'HAZE" /> 

<xsd:enumeration value="SNDSTR" /> 

<xsd:enumeration value="SMOKE " /> 

<xsd:enumeration value="NKN" /> 
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<xsd:enumeration value = "" /> 

<! xsd: restriction > 

</xsd:simpleType> 

- <! —break in schema.- - > 

- <xsd:element name ="Wind.categoryCode"> 

- <xsd:simpleType> 

- <xsd: restriction base="xsd:string"> 

<xsd:enumeration value="CONST" /> 

<xsd:enumeration value="GUST" /> 

<xsd:enumeration value="NKN" /> 

<xsd:enumeration value="SQUAL" /> 

<xsd:enumeration value="TRBLEX" /> 

<xsd:enumeration value="TRBLLI " /> 

<xsd:enumeration value="TRBLMO" /> 

<xsd:enumeration value="TRBLSE" /> 

<xsd:enumeration value="VRB" /> 

<xsd:enumeration value = "" /> 

</xsd: restriction > 

</xsd:simpleType> 

</ xsd: element > 

<xsd:element name ="Wind.directionAngle" type="xsd:decimal" /> 

<xsd:element name ="Wind.id" type="xsd:long" /> 

<xsd:element name ="Wind.speedRate" type="xsd:decimal" /> 

- <xsd:element name ="WindTable"> 

- <xsd:complexType> 

- <xsd:sequence> 

<xsd:element ref="Wind" maxOccurs ="unbounded" /> 

</xsd: sequence> 

</xsd:complexType> 

<! xsd: element > 

<xsd:element name -'ownerl d" type="xsd:long" /> 

<xsd:element name =' updateSequenceNumber" type="xsd:long" /> 

<! xsd: schema > 
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APPENDIX L. GENERIC HUB COMPLIANT OPERATION ORDER 


A. INTRODUCTION 

This is a fraction of a GH compliant order that follows the rules of the GH schema. As this order is in excess of 142 pages, it 
is not included it its entirety. Data was retrieved from each section of the order in order to portray enough information to obtain a 
reasonable appreciation of its contents. This is what the order in Appendix J must transform into to be compliant with the database. 
Franciso Loaiza of the Institute for Defense Analysis generated this order. 

B. GH OPERATION ORDER 

- cr¬ 
edited with XML Spy v4.0 U beta 3 build Aug 24 2001 (http://www.xmlspy.com) by FRANCISCO L LOAIZA (SED) 

-- > 

<GH4Complete xmlns: xsi="http:/ / www.w3.org/ 2001/ XMLSchema-instance" 

xsi: noNamespaceSchemaLocation- 'C :\ Program Files\ Altova\ XML Spy Suite\ GH4Complete_ 3b.xsd"> 

- <ObjectltemTable> 

- <Objectltem> 

<0bjectltem.id>555550001</0bjectltem.id> 

cObjectltern.name >BLT1/ 4</Objectl tern.name > 

cObjectl tern. categoryCode>OR</Objectl tern. categoryCode> 

cupdateSequenceNumber>777771234567890< updateSequencel\lumber> 

cownerl d>81234567890</ownerl d> 

</Objectl tem> 

- cObjectltem> 

cObjectl tern, id >5 55 550002 c/Objectltem.id> 
cObjectl tern, name >ALPHAc/Objectl tern, name > 
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<Obj ectl tern. categoryCode>OR</Objectl tern. categoryCode> 
<updateSequenceNumber>777771234567890< updateSequenceNumber> 
<ownerl d>81234567890</ownerl d> 

<Objectl tem> 

<Objectltem> 

<Obj ectl tem. id >555550003 </ Obj ectl tem. id > 

<0bj ectl tem. name >1 st PLATOONc/ Obj ectl tem. name > 

<Obj ectl tem. categoryCode>OR</ Obj ectl tem. categoryCode> 
<updateSequencel\lumber>777771234567890< updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

<0bjectl tem> 

<Objectltem> 

<0bj ectl tem. id >555550004 </ Obj ectl tem. id > 

<0bj ectl tem. name >2nd PLATOON</Objectltem.name> 

<0bj ectl tem. categoryCode >0 R</ Obj ectl tem. categoryCode > 
<updateSequencel\lumber>777771234567890< updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

<0bjectl tem> 

<Objectltem> 

<0bj ectl tem. id>555550005 </ Obj ectl tem. id > 

<0bj ectl tem. name >3rd PLATOON</Objectltem.name > 

<0bj ectl tem. categoryCode >OR</ Obj ectl tem. categoryCode > 
<updateSequencel\lumber>777771234567890< updateSequencel\lumber> 
cownerl d >81234567 890 </ownerl d> 

<Objectl tem> 

<Objectltem> 

<Obj ectl tem. id >555550006 </ Obj ectl tem. id > 

<Obj ectl tem. name >1 nsertStartPointc/ Obj ectl tem. name > 

<0bj ectl tem. categoryCode >FE</ Obj ectl tem. categoryCode > 
<updateSequencel\lumber>777771234567890< updateSequenceNumber> 
<ownerl d>81234567890</ownerl d> 

<Objectl tem> 

<Objectltem> 
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cObjectltem. id >5 55 550007 </Objectltem.id> 

<Objectltem.name >Beach Landing Sitec/ Objectltem.name > 
<Objectltem.categoryCode>FE</Obj ectltem.categoryCode> 
cupdateSequencel\lumber>77777 1234567890c/ updateSequenceNumber> 
<ownerl d>81234567890</ownerl d> 
c/Objectl tem> 

<Objectltem> 

<Objectl term. id>555550008 </Objectl term, id > 

<Objectltem.name >1 nfilStartPoint</ Objectltem.name > 

<Objectl tern. categoryCode>FE</Objectl tern. categoryCode> 
cupdateSequencel\lumber>777771234567890< updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 
c/Objectl tem> 

<Objectltem> 

<Objectl tern. id>555550009 </Objectl tern, id > 
cObjectl tem. name >1 nfilEndPoint</Objectl tern, name > 

<Objectl tern. categoryCode>FE</Objectl tern. categoryCode> 
<updateSequenceNumber>777771234567890<y updateSequenceNumber> 
<ownerl d>81234567890</ownerl d> 
c/Objectl tem> 

<Objectltem> 

<0bjectltem.id>555550010</0bjectltem.id> 

<Objectltem.name >1 nfilWaypoint</Objectltem.name > 
cObjectl tem. categoryCode>FE</Objectl tem.categoryCode> 
cupdateSequencel\lumber>777771234567890< updateSequencel\lumber> 
cownerl d>81234567890</ownerld> 
c/Objectl tem> 
cObjectl tem> 

c0bjectltem.id>555550011c/0bjectltem.id> 
cObjectl tem. name >1 nfilWaypointc/Objectltem.name > 
cObjectl tem. categoryCode>FEc/Objectl tem.categoryCode> 
cupdateSequenceNumber>777771234567890< updateSequenceNumber> 
cownerl d >812 345 67 890 c/ ownerl d> 
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<Objectl tem> 

<Objectltem> 

<0bjectltem.id>555550012</0bjectltem.id> 

<Objectltem.name >1 nfilWaypoint</Objectl tern.name > 

<Objectl tern. categoryCode>FE</Objectl tern. categoryCode> 
<updateSequenceNumber>777771234567890</updateSequenceNumber> 
<ownerl d>81234567890</ownerl d> 

<Objectl tem> 

<Objectltem> 

<0bjectltem.id>555550013</0bjectltem.id> 

<Objectl tern, name >ObjStartPoint</Objectl tern, name > 

<Objectl tern. categoryCode>FE</Objectl tern. categoryCode> 
<updateSequenceNumber>777771234567890< updateSequenceNumber> 
<ownerl d>81234567890</ownerl d> 

<Objectl tem> 

<Objectltem> 

<0bjectltem.id>555550014</0bjectltem.id> 

<Objectl tern, name >Obj EndPoint </Objectl tern, name > 

<Objectl tern. categoryCode>FE</Objectl tern. categoryCode> 
<updateSequencel\lumber>777771234567890</ updateSequenceNumber> 
<ownerl d>81234567890</ownerl d> 

<Objectl tem> 

<Objectltem> 

<0bjectltem.id>555550015</0bjectltem.id> 

<Objectl tern, name >ExfilStartPoint</Objectl tern, name > 

<Objectl tern. categoryCode>FE</Objectl tern. categoryCode> 
<updateSequenceNumber>777771234567890</updateSequenceNumber> 
<ownerl d>81234567890</ownerl d> 

<Objectl tem> 

<Objectltem> 

<0bjectltem.id>555550016</0bjectltem.id> 

<Objectl tern, name >ExfiI EndPoint </Objectl tem. name > 

<Objectl tern. categoryCode>FE</Objectl tern. categoryCode> 
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<updateSequencel\lumber>777771234567890<7 updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

<Objectl tem> 

<Objectltem> 

<0bjectltem.id>555550017 </Objectltem.id> 

<Objectltem.name >ExfilWaypoint</ Objectltem.name> 
<Objectltem.categoryCode>FE</Objectltem.categoryCode> 
<updateSequenceNumber>777771234567890< updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

<Objectl tem> 

<Objectltem> 

<0bjectltem.id>555550018</0bjectltem.id> 

<Objectltem.name >ExfilWaypoint</ Objectltem.name> 
<Objectltem.categoryCode>FE</Objectltem.categoryCode> 
<updateSequencel\lumber>777771234567890</ updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

<Objectl tem> 

<Objectltem> 

<Obj ectltem. id >555550019 </Objectltem. id > 

<Objectltem.name >ExtractionStartPoint</ Objectl tern, name > 
cObjectl tern. categoryCode>FE</Objectl tern. categoryCode> 
<updateSequencel\lumber>777771234567890<7 updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

<Objectl tem> 

<Objectltem> 

<Obj ectltem. id >5 55 550020 </ Objectl tern, id > 

<Objectltem.name >ExtractionEndPoint</Objectltem.name > 

<Objectl tern. categoryCode>FE</ Objectl tern.categoryCode> 
<updateSequencel\lumber>777771234567890<7 updateSequenceNumber> 
<ownerl d>81234567890</ownerl d> 

</ Objectl tem> 

<Objectltem> 

<Obj ectltem. id >5 55 550021</ Objectl tern, id > 
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<Objectltern.name >Pendleton AF < Objectl tern, name > 

<Objectl tern. categoryCode>FE</Objectl tern. categoryCode> 
<updateSequenceNumber>777771234567890< updateSequenceNumber> 
<ownerl d>81234567890</ownerl d> 

<Objectl tem> 

<Objectltem> 

<0bjectltem.id>555550022</0bjectltem.id> 

<Objectl tern, name >AAAV</ Objectl tern, name > 

<Objectl tern. categoryCode>FE</Objectl tern. categoryCode> 
<updateSequencel\lumber>777771234567890</ updateSequenceNumber> 
<ownerl d>81234567890</ownerl d> 

<Objectl tem> 

<Objectltem> 

<Objectl tern. id>555550023 </ Objectl tern, id > 

<Objectl tern, name >AAAV</ Objectl tern, name > 

<Objectl tern. categoryCode>FE</ Objectl tern.categoryCode> 
<updateSequencel\lumber>777771234567890< updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

</Objectl tem> 

<Objectltem> 

<Objectl tern, id >555550024 </ Objectl tern, id > 

<0bjectl tern, name >AAAV</ Objectl tern, name > 
<Objectltem.categoryCode>FE</Obj ectltem.categoryCode> 
<updateSequencel\lumber>777771234567890< updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

<0bjectl tem> 

<Objectltem> 

<0bjectl tern, id >555550025 </ Objectl tern, id > 

<0bjectl tern, name >USCI NCCENT </ Objectl tern, name > 

<0bjectl tern. categoryCode>OR</ Objectl tern. categoryCode> 
<updateSequenceNumber>777771234567890</ updateSequenceNumber> 
cownerl d>81234567890</ownerl d> 

<Objectl tem> 
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- <Objectltem> 

<Objectltem. id>555550026</0bjectl tem. id> 

<Objectltem.name >1 nsertEndPointc/ Objectl tem. name > 
<Objectltem.categoryCode>FE</Obj ectltem.categoryCode> 
<updateSequenceNumber>777771234567890< updateSequenceNumber> 
<ownerl d>81234567890</ownerl d> 

</Objectl tem> 

<ObjectltemTable> 

<0 bj ectT y peTa b I e > 

- <ObjectType> 

<0bj ectType. id >77777000 l</ObjectType. id > 
<ObjectType.nationalityCode>US</ObjectType.nationalityCode> 
cObjectType.name >Battalion Landing Team</ObjectType.name > 

<Obj ectType. dummy lndicatorCode>NO</Obj ectType. dummy I ndicatorCode> 
<Obj ectType. categoryCode>OR</ObjectType.categoryCode> 
<updateSequenceNumber>777771234567890<updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

</ObjectType> 

- <ObjectType> 

<Obj ectType. id >777770002 </Obj ectType. id > 

<Obj ectType. nationalityCode >US</Obj ectType. nationalityCode> 
<ObjectType.name >Company </ObjectType.name > 

<Obj ectType. dummyl ndicatorCode>NO</Obj ectType. dummy I ndicatorCode> 
<Obj ectType. categoryCode>OR</ObjectType.categoryCode> 
<updateSequenceNumber>777771234567890< updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

</ObjectType> 

- <ObjectType> 

<Obj ectType. id >777770003 </0bj ectType. id > 
<ObjectType.nationalityCode>US</ObjectType.nationalityCode> 
<ObjectType.name >Platoon</ObjectType.name > 

<Obj ectType. dummyl ndicatorCode>NO</Obj ectType. dummy I ndicatorCode> 
<Obj ectType. categoryCode>OR</ObjectType.categoryCode> 
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<updateSequencel\lumber>777771234567890<7 updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

<ObjectType> 

<ObjectType> 

<ObjectType.id>777770004</ObjectType.id> 
<ObjectType.nationalityCode>US</Obj ectType.nationalityCode> 
<ObjectType.name >1 nsertion Point</ObjectType.name > 
<ObjectType.dummyl ndicatorCode>NO</ObjectType.dummyl ndicatorCode> 
<Obj ectType.categoryCode>FE</ObjectType.categoryCode> 
<updateSequencel\lumber>777771234567890</ updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

<70bjectType> 

<ObjectType> 

<Obj ectType. id >777770005 </ObjectType. id > 
<ObjectType.nationalityCode>US</ObjectType.nationalityCode> 
<ObjectType.name >1 nfiltration Point </ObjectType.name > 

<Obj ectType. dummyl ndicatorCode>NO</Obj ectType. dummy I ndicatorCode> 
<ObjectType.categoryCode>FE</ObjectType.categoryCode> 
<updateSequencel\lumber>777771234567890<7 updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

<ObjectType> 

<Obj ectType > 

<Obj ectType. id >777770006</0bj ectType. id > 
<ObjectType.nationalityCode>US</Obj ectType. nationalityCode> 
<ObjectType.name >Waypoint</ObjectType.name > 

<Obj ectType. dummyl ndicatorCode>NO</Obj ectType. dummy I ndicatorCode> 
<Obj ectType. categoryCode>FE</ObjectType.categoryCode> 
<updateSequencel\lumber>777771234567890<y updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

<ObjectType> 

<ObjectType> 

<Obj ectType. id >777770007 </Obj ectType. id > 

<Obj ectType. nationalityCode >US</Obj ectType. nationalityCode> 
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cObjectType.name >Objective Point</ObjectType.name > 
<ObjectType.dummyl ndicatorCode>NO</ObjectType.durnmyl ndicatorCode> 
<ObjectType.categoryCode>FE</ObjectType.categoryCode> 

<u pdateSequenceNumber>77777 1234567890 </ updateSequenceNumber> 
<ownerl d>81234567890</ownerl d> 

<ObjectType> 

<ObjectType> 

<ObjectType. id >777770008 </ObjectType. id > 
<ObjectType.nationalityCode>US</Obj ectType.nationalityCode> 
<ObjectType.name >Exfiltration Point </ ObjectType.name > 
<ObjectType.dummyl ndicatorCode>NO</ObjectType.dumrnyl ndicatorCode> 
<ObjectType.categoryCode>FE</ObjectType.categoryCode> 
cupdateSequencel\lumber>777771234567890< updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

<ObjectType> 

<ObjectType> 

<Obj ectType. id >777770009 </ObjectType. id > 
<ObjectType.nationalityCode>US</ObjectType.nationalityCode> 
cObjectType.name >Extraction Pointc/ ObjectType.name > 
cObjectType.dummyl ndicatorCode>NO</Obj ectType. dummy I ndicatorCode> 
<Obj ectType. categoryCode>FE</ObjectType.categoryCode> 
cupdateSequencel\lumber>777771234567890<7 updateSequencel\lumber> 
cownerl d>81234567890</ownerl d> 

<ObjectType> 

<Obj ectType > 

<Obj ectType. id >777770010</0bj ectType. id > 

<Obj ectType. nationalityCode>US</Obj ectType. nationalityCode> 
cObjectType.name >Airport Field c/ObjectType.name > 
cObjectType.dummyl ndicatorCode>NO c/ObjectType. dummy I ndicatorCode> 
cObj ectType. categoryCode >F Ac/ Obj ectType. categoryCode > 
cu pdateSequenceNumber>77777 1234567890 c/ updateSequencel\lumber> 
cownerl d >812 345 67 890 c/ ownerl d> 
c/0bjectType> 


171 


- <ObjectType> 

<ObjectType. id >77777001 l</ObjectType. id > 
<ObjectType.nationalityCode>US</ObjectType.nationalityCode> 
<ObjectType.name >Armored Vehicle </ObjectType.name > 

<Obj ectType.dummyl ndicatorCode>NO</ObjectType.durnmyl ndicatorCode> 
<Obj ectType.categoryCode>MA</ObjectType.categoryCode> 
<updateSequenceNumber>777771234567890<updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

</ObjectType> 

- <ObjectType> 

<ObjectType. id >777770012 </ObjectType. id > 
<ObjectType.nationalityCode>US</ObjectType.nationalityCode> 
<ObjectType.name >CI NC </ObjectType.name > 

cObjectType.dummyl ndicatorCode>NO</ ObjectType.dummyl ndicatorCode> 
<ObjectType.categoryCode>OR</ObjectType.categoryCode> 
<updateSequencel\lumber>777771234567890<updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

</ObjectType> 

<ObjectTypeTable > 

<OrganisationTable > 

- <Organisation> 

Organisation. nicknameN a me >BLT1/ 4</Organisation.nicknameName > 
Organ isation. categoryCode >UN</ Organ isation. categoryCode > 

Organisation, id >5 55550001</ Organisation, id > 

<updateSequenceNumber>777771234567890< updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

</Organisation> 

- Organisation> 

Organisation. nicknameN a me >USCI NCCENT </ Orga n isation. nicknameName > 
Organ isation. categoryCode >UN</ Organ isation. categoryCode > 

Organisation, id >5 55550025 </ Organ isation. id> 

<updateSequencel\lumber>777771234567890< updateSequenceNumber> 
<ownerl d>81234567890</ownerl d> 
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</Organisation> 

<70rganisationTable> 

<ReferenceTable > 

- <Reference> 

<Reference.id>5250001</ Reference, id > 

<Reference.transmittalTypeCode>TELEX</ Reference. transmittalTypeCode> 

<Reference. sou rceT ext >J TF 1 67 </ Reference, sou rceT ext > 

<Reference.securityClassificationCode>NU </ Reference. securityClassificationCode> 
<Reference.identificationText >Exercise Id: EXER; NickName: XMLOl; Messageld: MSGID; 
MsgFormat: ORDER; SerialNumber: 129005; OrderTy: ORDTY; PlanTy: FRAGORD; Authority: 
USCINCCENT; OpOrderNr: A101</ Reference.identificationText > 

<Reference.formatCode>USMTF <J Reference.formatCode> 
<updateSequenceNumber>777771234567890<updateSequenceNumber> 

<ownerl d>81234567890</ownerl d> 

</ Reference> 

- <Reference> 

<Reference. id >5250002 </ Reference, id > 

<Reference.transmittalTypeCode>TELEX</ Reference. transmittalTypeCode> 

<Reference.sourceText >J TF 167</ Reference, sou rceText > 

<Reference.securityClassificationCode>NU </ Reference. securityClassificationCode> 

<Reference. identificationText >Exercise Id: EXER; NickName: XMLOl; Messageld: MSGI D; 
MsgFormat: ORDER; SerialNumber: 129005; OrderTy: ORDTY; PlanTy: FRAGORD; Authority: 
USCINCCENT; OpOrderNr: A101</ Reference.identificationText > 

<Reference.formatCode>USMTF </ Reference.formatCode> 
<updateSequenceNumber>777771234567890<updateSequenceNumber> 
cownerl d>81234567890</ownerl d> 

</ Reference> 

<1 ReferenceTable > 

<ReportingDataTable > 

- <ReportingData> 

<ReportingData.id>22220001</ ReportingData.id> 

<ReportingData.timingCategoryCode>RDABST</ Reporting Data. timingCategoryCode> 
<ReportingData.reportingTime >54000</ ReportingData.reportingTime > 
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<ReportingData.reportingDate>36518 </ ReportingData.reportingDate> 
<ReportingData.credibilityCode>TRSTED</ ReportingData.credibilityCode> 
<ReportingData.countingl ndicatorCode>NOc/ ReportingData.countingl ndicatorCode> 
<ReportingData.confirmation! ndicatorCode>NO</ ReportingData.confirmation! ndicatorCode> 
<ReportingData.categoryCode>REP</ Reporting Data. categoryCode> 

<Reference. id >5250001</ Reference, id > 

<ReportingOrganisation.id >555550001</ ReportingOrganisation.id> 
cupdateSequenceNumber>777771234567890< updateSequencel\lumber> 

<ownerl d>81234567890</ownerl d> 

</ ReportingData> 

<!— AdditonalReportingData follows. - - > 

- <ObjectltemTypeTable> 

- <ObjectltemType> 

<ObjectltemType.index>3 3 300001 </Objectl temType. index> 
<0bjectltem.id>555550001</0bjectltem.id> 

<ObjectType. id >77777000 l</ObjectType. id > 

<ReportingData.id>22220001</ ReportingData. id > 

cupdateSequencel\lumber>777771234567890<updateSequencel\lumber> 

<ownerl d>81234567890</ownerl d> 
c/Objectl temType > 

<! — Additonal Objectltem TypeTable data follows - - > 

- <FeatureTable> 

- <Feature> 

<Feature.categoryCode>CF<yFeature.categoryCode> 

<Featu re. id>555550006</Feature. id> 

<updateSequencel\lumber>777771234567890c/updateSequencel\lumber> 
cownerld >81234567890 </ownerld> 

<1 Feature > 

<! —Additonal FeatureTable data follows.- - > 

- cLocationTable > 

- <Location> 

cLocation.id >88880001c/ Location.id > 
cLocation.categoryCode>PTc/ Location. categoryCode> 
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<updateSequenceNumber>77777123456789(XupdateSequenceNumber> 

<ownerl d>81234567890</ownerl d> 

<1 Location > 

- <! — Additonal LocationTable data follows.- - > 

<FeatureLocationTable> 

- <FeatureLocation > 

<FeatureLocation.index>111110001</FeatureLocation.index> 

<FeatureLocation,accuracyQuantity>0</FeatureLocation.accuracyQuantity> 

<Location.id >88880001 </ Location, id > 

<Feature. id >55 5550006</ Feature, id > 

<ReportingData. id >22220002 </ ReportingData.id> 

<updateSequenceNumber>777771234567890< updateSequencel\lumber> 

<ownerl d>81234567890</ownerl d> 

</FeatureLocation > 

- <! —Additonal FeatureLocationTable data follows. - - > 

<PointTable > 

- <Point> 

<Poi nt. vertical PrecisionCode >10M</ Point, vertical PrecisionCode> 

<Point.horizontalPrecisionCode>10M</Point.horizontalPrecisionCode> 

<Point.categoryCode>ABS</Point.categoryCode> 

<Poi nt. id >88 880001</ Point, id > 

<updateSequenceNumber>777771234567890< updateSequenceNumber> 

<ownerl d>81234567890</ownerl d> 

</Point > 

- <! —Additonal PointTable data follows.- - > 

<AbsolutePointTable > 

- <AbsolutePoint > 

<AbsolutePoint. longitudeCoordinate>- 131.43425</AbsolutePoint.longitudeCoordinate> 
<AbsolutePoint.latitudeCoordinate>- 44.65465 </Abso I utePoint.latitudeCoordinate> 
<AbsolutePoint.elevationCategoryCode>LOC </AbsolutePoint.elevationCategoryCode> 
<Absol utePoint. id >88880001< AbsolutePoint. id > 

<updateSequenceNumber>777771234567890< updateSequenceNumber> 
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cownerl d>81234567890</ownerl d> 
<AbsolutePoint > 

- <! — Additonal AbsolutePointTable data follows. - - > 


<ActionTable > 

- <Action> 

<Action. id >9999900001 </ Action, id > 

<Action.name >Secure Camp Pendleton</ Action.name> 
<Action.categoryCode >ACTTA </ Action. categoryCode > 
<updateSequenceNumber>777771234567890< updateSequenceNumber> 
cownerl d>81234567890</ownerl d> 

<J Action > 

- <Action> 

cAction. id >9999900002 </ Action, id > 
cAction.name >1 nsert Troops </ Action.name > 

<A ction. categoryCode >ACTTA</ Action. categoryCode > 
<updateSequenceNumber>777771234567890< updateSequencel\lumber> 
cownerl d>81234567890</ownerl d> 

</ Action > 

- cAction > 

cAction. id >9999900003 </ Action, id > 

cAction.name >Move Alpha Company to I Pic/ Action.name > 
cAction. categoryCode >ACTTA </ Action. categoryCode > 
cupdateSequenceNumber>777771234567890<updateSequencel\lumber> 
cownerl d >812 345 67 890 c/ ownerl d> 

</ Action > 

- cAction > 

cAction. id >9999900004 </ Action, id > 

cAction.name >Move Alpha Company to I P2c/ Action.name > 
cA ction. categoryCode >ACTTAc/ Action. categoryCode > 
cupdateSequenceNumber>777771234567890< updateSequenceNumber> 
cownerl d >812 345 67 890 c/ ownerl d> 
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</ Action > 

<Action > 

<Action. id >9999900005 </ Action, id > 

<Action.name >1 nfiltrate with Alpha Company </ Action.name> 

<A ction. categoryCode >ACTTA</ Action. categoryCode> 
<updateSequencel\lumber>777771234567890<7 updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

</ Action > 

<Action > 

<A ction. id >9999900006 </ Action, id > 

<Action.name >Move Alpha Company to WP1 </ Action.name > 

<A ction. categoryCode >ACTTA</ Action. categoryCode > 
<updateSequenceNumber>777771234567890</ updateSequenceNumber> 
cownerl d>81234567890</ownerl d> 

</ Action > 

<Action > 

<A ction. id >9999900007 </ Action, id > 

<Action.name >Move Alpha Company to WP2</ Action.name> 

<A ction. categoryCode >ACTTA</ Action. categoryCode > 
<updateSequencel\lumber>777771234567890</ updateSequenceNumber> 
<ownerl d>81234567890</ownerl d> 

</ Action > 

<Action > 

<A ction. id >9999900008 </ Action, id > 

<Action.name >Move Alpha Company to WP3 </ Action.name > 

<A ction. categoryCode >ACTTA</ Action. categoryCode > 
<updateSequencel\lumber>777771234567890<7 updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

</ Action > 

<Action > 

<A ction. id >9999900009 </ Action, id > 

<Action.name >Move Alpha Company to I P</ Action.name > 

<A ction. categoryCode >ACTTA</ Action. categoryCode > 


177 


<updateSequencel\lumber>777771234567890<7 updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

<j Action > 

<Action > 

<Action. id >9999900010 </ Action, id > 

<Action.name >Secure Pendleton AF <J Action.name > 

<A ction. categoryCode >ACTTA</ Action. categoryCode> 
<updateSequenceNumber>777771234567890</ updateSequenceNumber> 
<ownerl d>81234567890</ownerl d> 

</ Action > 

<Action > 

<A ction. id >9999900011</ Action, id > 

<Action.name >Secure I P</ Action.name > 

<A ction. categoryCode >ACTTA</ Action. categoryCode > 

<u pdateSequenceNumber>77777 1234567890 </ updateSequenceNumber> 
cownerl d>81234567890</ownerl d> 

<7 Action > 

<Action > 

<A ction. id >9999900012 </ Action, id > 

<Action.name >Defend I P</ Action.name> 

<A ction. categoryCode >ACTTA</ Action. categoryCode > 
<updateSequencel\lumber>777771234567890< updateSequenceNumber> 
<ownerl d>81234567890</ownerld> 

<J Action > 

<Action > 

<A ction. id >9999900013 </ Action, id > 

<Action.name >Move to I P2<J Action.name > 

<A ction. categoryCode >ACTTA</ Action. categoryCode > 
<updateSequencel\lumber>777771234567890<7 updateSequenceNumber> 
<ownerl d>81234567890</ownerl d> 

<7 Action > 

<Action > 

<A ction. id >9999900014 </ Action, id > 
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<Action.name >Defend I P2</ Action.name > 

<A ction. categoryCode >ACTTA</ Action. categoryCode> 
<updateSequenceNumber>777771234567890</ updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

<J Action > 

<Action > 

<A ction. id >9999900015 </ Action, id > 

<Action.name >Move to I P3 <7 Action, name > 

<A ction. categoryCode >ACTTA</ Action. categoryCode > 
<updateSequenceNumber>777771234567890</ updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

</ Action > 

<Action > 

<A ction. id >9999900016 </ Action, id > 

<Action.name >Defend I P3</ Action.name > 

<A ction. categoryCode >ACTTA</ Action. categoryCode > 
<updateSequencel\lumber>777771234567890< updateSequenceNumber> 
<ownerl d>81234567890</ownerl d> 

<J Action > 

<Action > 

<A ction. id >9999900017 </ Action, id > 

<Action.name >Move to I P</ Action.name > 

<A ction. categoryCode >ACTTA</ Action. categoryCode > 
<updateSequencel\lumber>777771234567890<7 updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

<J Action > 

<Action > 

<A ction. id >9999900018 </ Action, id > 

<Action.name >Move to I P</ Action.name > 

<A ction. categoryCode >ACTTA</ Action. categoryCode > 
<updateSequenceNumber>777771234567890</ updateSequenceNumber> 
cownerl d>81234567890</ownerl d> 

</ Action > 
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<Action > 

<Action. id >9999900019 </ Action, id > 

<Action.name >Exfiltrate Alpha Company </ Action.name > 

<A ction. categoryCode >ACTTA</ Action. categoryCode> 

<u pdateSequenceNumber>77777 1234567890 </ updateSequenceNumber> 
<ownerl d>81234567890</ownerl d> 

</ Action > 

<Action > 

<A ction. id >9999900020 </ Action, id > 

<Action.name >Move Alpha Company to WP3</ Action.name> 

<A ction. categoryCode >ACTTA</ Action. categoryCode > 
<updateSequencel\lumber>777771234567890< updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

</ Action > 

<Action > 

<A ction. id >9999900021 </ Action, id > 

<Action.name >Move Alpha Company to WP2</ Action.name> 

<A ction. categoryCode >ACTTA</ Action. categoryCode > 
<updateSequenceNumber>777771234567890< updateSequenceNumber> 
<ownerl d>81234567890</ownerl d> 

</ Action > 

<Action > 

<A ction. id >9999900022 </ Action, id > 

<Action.name >Move Alpha Company to WP1</ Action.name> 

<A ction. categoryCode >ACTTA</ Action. categoryCode > 
<updateSequenceNumber>777771234567890< updateSequenceNumber> 
cownerl d>81234567890</ownerl d> 

</ Action > 

<Action> 

<A ction. id >999990002 3 </ Action, id > 

<Action.name >Extract Alpha Company </ Action.name > 

<A ction. categoryCode >ACTTA</ Action. categoryCode > 
<updateSequencel\lumber>777771234567890<y updateSequencel\lumber> 


180 


cownerl d>81234567890</ownerl d> 

</ Action > 

- <Action> 

<Action. id >9999900024 </ Action, id > 

<Action.name >Move to BLS</ Action.name> 

<A ction. categoryCode >ACTTA</ Action. categoryCode> 
<updateSequenceNumber>777771234567890< updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

<J Action > 

- <Action> 

<A ction. id >999990002 5 </ Action, id > 

<Action.name >Move to Extraction Point</ Action.name > 
<Action.categoryCode>ACTTA </ Action. categoryCode > 
<updateSequenceNumber>777771234567890< updateSequenceNumber> 
<ownerl d>81234567890</ownerl d> 

</ Action > 

- <Action> 

<A ction. id >999990002 6 </ Action, id > 

<Action.name >Move to Exfiltration End Point</ Action.name > 

<Action. categoryCode >ACTTA </ Action. categoryCode > 
<updateSequencel\lumber>777771234567890<updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

</ Action > 

</ActionTable > 

<CandidateTargetListTable > 

- <CandidateTargetList> 

<CandidateTargetList.id>6566</ CandidateTargetList.id> 

<CandidateTargetList.name >The Pendleton AF </CandidateTargetList.name > 
<ReportingData.id>22220001</ ReportingData.id> 

<updateSequenceNumber>777771234567890<updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

</CandidateTargetl_ist > 

<CandidateTa rgetListTable> 
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<CandidateTargetDetailTable > 

- <CandidateTargetDetail> 

<CandidateTa rgetDetail.index>1000001</CandidateTargetDetail.index> 
<CandidateTargetDetail.schemeCode>SI TENR</CandidateTargetDetail.schemeCode> 
<CandidateTargetDetail.priorityQuantity>l</CandidateTa rgetDetail.priorityQuantity> 
<CandidateTargetDetail.labelText / > 

<CandidateTargetDetail.focusTypeCode>NOS</CandidateTargetDetail.focusTypeCode> 

<Ca ndidateTargetDetail. discrim in atorCode>CTD I TM</Cand idateTargetDetail. discrim inatorCode> 
<CandidateTargetList.id>6566</ CandidateTargetList.id> 
<updateSequenceNumber>777771234567890<updateSequencel\lumber> 

<ownerl d>81234567890</ownerl d> 

</CandidateTargetDetail> 

- <! — Additonal CandidateTargetDetailTable data follows.- - > 

<ActionTaskTable > 

- <ActionTask> 

<ActionTask.plannedEndTime >2 5 200 < ActionTask.plannedEndTime > 

<ActionTask. minimumDu ration >0</ ActionTask. minim um Du ration > 

<ActionTask. esti mated Du ration >0 </ ActionTask. estimated Du ration > 

<ActionTask. maxi mu mDuration>0</ ActionTask. maximumDu ration > 
<ActionTask.plannedStartDate>3651 8 </ ActionTask. plannedStartDate> 
<ActionTask.plannedStartTime >54000 </ ActionTask.plannedStartTime > 
<ActionTask.startPrecisionCode>HR</ActionTask.startPrecisionCode> 

<A ctionTask. categoryCode >ORD </ ActionTask. categoryCode> 

<ActionTask. planned End Date>365 19 </ ActionTask. plannedEndDate> 

<A ctionTask. end PrecisionCode >HR</ ActionTask. end PrecisionCode> 
<ActionTask.endQualifierCode>NLT</ ActionTask. endQua I ifierCode> 

<A ctionTask. priorityCode >1</ ActionTask. priorityCode> 

<ActionTask.verbPhraseCode>SECURE </ ActionTask. verbPhraseCode> 
<ActionTask.startQualifierCode>NLT </ ActionTask. startQua I if ierCode> 

<A ctionTask. id >9999900001</ ActionTask. id> 

<CandidateTargetList.id>6566</ CandidateTargetList.id> 
<updateSequenceNumber>777771234567890< updateSequencel\lumber> 

<ownerl d>81234567890</ownerl d> 
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<MctionTask> 

<ActionTask> 

<ActionTask. plannedEndTi me >64 800 </ ActionTask.plannedEndTime > 
<ActionTask. minimumDu ration >0</ ActionTask. minim um Du ration > 
<ActionTask.estimatedDuration >0 </ ActionTask.estimatedDuration > 
<ActionTask. maxi mu m Du ration >0</ ActionTask. maxi mum Du ration > 
<ActionTask.plannedS tart Date>36518 </ ActionTask. plannedStartDate> 
<ActionTask.plannedStartTime >54000 </ ActionTask.plannedStartTime > 

<A ctionTask. startPrecisionCode >HR</ ActionTask. startPrecisionCode> 

<A ctionTask. categoryCode >ORD </ ActionTask. categoryCode> 

<ActionTask. planned End Date>36518 </ ActionTask. plannedEndDate> 

<A ctionTask. end PrecisionCode >HR</ ActionTask. end PrecisionCode> 
<ActionTask.endQualifierCode>NLT</ ActionTask. endQua I ifierCode> 

<A ctionTask. priorityCode >1</ ActionTask. priorityCode> 
<ActionTask.verbPhraseCode>l NSERT</ActionTask.verbPhraseCode> 
<ActionTask.startQualifierCode>NLT </ ActionTask. startQua I if ierCode> 

<A ctionTask. id >9999900002 </ ActionTask. id > 

<CandidateTargetList. id >6566 </ CandidateTargetList.id> 
<updateSequencel\lumber>777771234567890< updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

<ActionTask> 

<ActionTask> 

<ActionTask.plannedEndTime >64 800 <J ActionTask.plannedEndTime > 

<A ctionTask. minimumDu ration >0</ ActionTask. minim um Du ration > 
<ActionTask. estimated Du ration >0 </ ActionTask. estimated Du ration > 
<ActionTask. maxi mu mDuration>0</ ActionTask. maximumDu ration > 
<ActionTask.plannedStartDate>3651 8 </ ActionTask. plannedStartDate> 
<ActionTask. plannedStartTi me >5 4000 </ ActionTask. plannedStartTi me > 

<A ctionTask. sta rtPrecisionCode >HR</ ActionTask. startPrecisionCode> 

<A ctionTask. categoryCode >ORD </ ActionTask. categoryCode > 

<ActionTask. planned End Date>36518 </ ActionTask. plannedEndDate> 

<ActionTask. end PrecisionCode >HR</ ActionTask. end PrecisionCode > 
<ActionTask.endQualifierCode>NLT</ ActionTask. endQua I ifierCode> 
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<ActionTask.priorityCode>l</ActionTask.priorityCode> 
<ActionTask.verbPhraseCode>MOVE</ActionTask.verbPhraseCode> 
<ActionTask.startQualifierCode>NLT </ActionTask.startQualifierCode> 

<ActionTask.id >9999900003 </ActionTask. id> 

<CandidateTargetList.id>6566</ CandidateTargetList.id> 
<updateSequencel\lumber>777771234567890<updateSequencel\lumber> 

<ownerl d>81234567890</ownerl d> 

</ActionTask> 

- <! — Additonal ActionTaskTable data follows.- - > 

<ActionFunctionalAssociationTable > 

- <ActionFunctionalAssociation > 

<Action Functional Association. index>33 1234500001</ Action Functional Association. index> 

<A ction Fu nctiona I Association. categoryCode >HSA</ Action Functiona I Association. categoryCode> 
<Obj ectAction. id >9999900001 </ Obj ectAction. id > 

<S ubjectA ction. id >9999900002 </SubjectA ction. id > 

<updateSequenceNumber>777771234567890<updateSequencel\lumber> 

<ownerl d>81234567890</ownerl d> 

<! Action Fu nctiona I Association > 

- <! —Additonal ActionFunctionalAssociationTable data follows. - - > 

<ActionResourceTable > 

- <ActionResource> 

<Action Resource. index>33 12345 60001 </ Action Resource. index> 

<Action Resource, qua I if ierCode>AUTH </ActionResource.qualifierCode> 
<ActionResource.criticalityl ndicatorCode>YES</ActionResource.criticalityl ndicatorCode> 
<Action Resource. categoryCode >R I </ Action Resource. categoryCode > 

<A ction. id >9999900001 </ Action, id > 

<AuthorisingOrganisation.id>5555 50025</AuthorisingOrganisation.id> 
<updateSequenceNumber>777771234567890<updateSequenceNumber> 

<ownerl d>81234567890</ownerl d> 

</ActionResource 

- <! —Additonal ActionResourceTable data follows. - - > 

<ActionResourcel temTable > 
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- <ActionResourceltem> 

<Action Resource. index>33 12345 60001 </ Action Resource. index> 

<Action. id >9999900001</ Action, id > 
<0bjectltem.id>555550001</0bjectltem.id> 

<updateSequenceNumber>777771234567890< updateSequenceNumber> 
<ownerl d>81234567890</ownerl d> 

</ActionResourcel tem> 

- <! — Additonal ActionResourceltemTable data follows.- - > 

<ActionObjectiveTable > 

- <ActionObjective> 

<ActionObjective.index>441234567001</ActionObjective. index> 
<ActionObj ective. priorityCode>l</ActionObjective.priorityCode> 
<ActionObjective.qualifierCode>AUTH </ActionObj ective. qua I ifierCode> 
<ActionObjective.categoryCode>OI </ ActionObj ective.categoryCode> 
<Action. id >9999900001 </ Action, id > 

<Authoris ingOrganisation.id>555550025</AuthorisingOrganisation.id> 
<updateSequenceNumber>777771234567890<updateSequenceNumber> 
<ownerl d>81234567890</ownerl d> 

<! ActionObj ective> 

- <! —Additonal ActionObjectiveTable data follows. - - > 

<ContextTable > 

- <Context > 

<Context. id >92220001 </ Context, id > 
cContext.name >SI TUATI ON</Context.name > 

<updateSequenceNumber>777771234567890< updateSequenceNumber> 
cownerl d>81234567890</ownerl d> 

<! Context > 

- <Context > 

<Context. id >92220002 </ Context, id > 

<Context.name >MI SSI ON</Context.name > 

<updateSequenceNumber>777771234567890<updateSequenceNumber> 
<ownerl d>81234567890</ownerl d> 
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</ Context > 

- <Context > 

<Context. id >92220003 </ Context, id > 

<Context.name >EXECUTI ON</ Context.name > 

cupdateSequenceNumber>777771234567890<updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

</ Context > 

- <Context > 

cContext. id >92220004 </ Context, id > 

<Context.name >ADMI N AND LOGI STI CS</ Context.name > 
<updateSequencel\lumber>777771234567890<updateSequencel\lumber> 
<ownerl d>81234567890</ownerl d> 

<! Context > 

- <Context > 

<Context. id >92220005 </ Context, id > 

cContext.name >COMMAND AND CONTROLc/ Context.name > 

<u pdateSequenceNumber>77777 1234567890c/ updateSequenceNumber> 
cownerl d>81234567890c/ownerl d> 

<J Context > 
c/ContextTable > 
cActionContextTable > 

- cActionContext > 

cActionContext.index>1001c/ActionContext.index> 
cActionContext.categoryCode>DESc/ActionContext.categoryCode> 
cContext. id >92220001 </ Context, id > 
cAction. id >9999900001 </ Action, id > 

cupdateSequencel\lumber>777771234567890<updateSequencel\lumber> 
cownerl d >812 345 67 890 c/ ownerl d> 
c/ActionContext > 

- c! — Additonal ActionContextTable data follows - - > 

cContextAssessmentTable > 

- cContextAssessment > 

cContextAssessment. index>1001 </ ContextAssessment. index> 
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cContextAssessment. effectiveTi me >54000 </ ContextAssessment.effectiveTi me > 
<ContextAssessment.effectiveDate>36518</ContextAssessment.effectiveDate> 

<ContextAssessment.text >A. GENERAL. REFER TO BASIC ORDER; B. ENEMY FORCES. REFER TO 
BASIC ORDER; C. FRIENDLY FORCES. REFER TO BASIC ORDER; D. ATTACHMENTS AND 
DETACHMENTS. ANNEX A (TASK ORGANIZATI ON) </ContextAssessment.text > 
cContext. id >92220001 </ Context, id > 

<ContextAssessingOrganisation.id>555550001</ContextAssessingOrganisation. id> 
<updateSequencel\lumber>777771234567890< updateSequencel\lumber> 
cownerl d>81234567890</ownerl d> 

<7ContextAssessment > 

<ContextAssessment > 

<ContextAssessment.index>1001 </ ContextAssessment. index> 

<ContextAssessment. effectiveTi me >54000 </ ContextAssessment. effecti veTi me > 

<ContextAssessment. effecti veDate>3 6518 </ ContextAssessment. effectiveDate> 

<ContextAssessment.text >AT H-HOUR, BLT 1/4 CONDUCTS AN AAAV RAID ACROSS RED BEACH 
AND PROCEEDS INLAND TO SEIZE ATF OBJECTIVE A. ONCE SEIZED, MAINTAIN SECURITY OF 
OBJ ECTIVE UNTIL RELI EVED BY TF APACHE. </ContextAssessment. text > 
cContext. id >92220002 </ Context, id > 

cContextAssessingOrganisation. id >555550001 </ContextAssessingOrganisation. id> 

<u pdateSequenceNumber>77777 1234567890 </ updateSequencel\lumber> 
cownerl d>81234567890</ownerl d> 
c/ContextAssessment > 
cContextAssessment > 

cContextAssessment.index>1001 </ ContextAssessment. index> 
cContextAssessment. effectiveTi me >54000 </ ContextAssessment. effecti veTi me > 
cContextAssessment. effectiveDate>3 6518 c/ ContextAssessment. effectiveDate> 

cContextAssessment.text >3. CONCEPT OF OPERATIONS. AT H-HOUR, BLT 1/4 CONDUCTS AN 
AMPHIBIOUS RAID TO SEIZE ATF OBJECTIVE A. THREE REINFORCED PLATOONS FROM 
COMPANY A WILL CONDUCT AN AAAV ASSAULT ACROSS RED BEACH AND PROCEED INLAND 
VIA PREDETERMINED ROUTE TO SEIZE ATF OBJECTIVE A. COMPANY A WILL SECURE THE 
OBJECTIVE AND REMAIN UNTIL RELIEVED BY TF APACHE. COMPANY B IS THE RESERVE. 
COMPANY A IS THE MAIN EFFORT AND WILL HAVE PRIORITY OF FIRES FOR THE DURATION 
OF THE OPERATI ON. </ ContextAssessment.text > 


187 


<Context. id >92220003 </ Context, id > 

<ContextAssessingOrganisation.id>555550001</ContextAssessingOrganisation. id> 
<updateSequencel\lumber>777771234567890</updateSequencel\lumber> 

<ownerl d>81234567890</ownerl d> 

</ContextAssessment > 

- <! — Additonal ContextAssessmentTable data follows - - > 

- <OrganisationActionTaskAssociationTable > 

- <OrganisationActionTaskAssociation > 

<OrganisationActionTaskAssociation.index>113301</OrganisationActionTaskAssociation.index> 
<OrganisationActionTaskAssociation.intentText >1. BATTALION COMMANDERS INTENT. CURRENTLY 
THERE IS Ml Nl MAL THREAT I N OUR ZONE. HOWEVER, MY CONCERN LI ES IN THE FACT THAT 
CIVILIAN REACTION IS UNCERTAIN AND THERE ARE GREAT NUMBERS OF THEM NEARBY. AS 
WE ARE DEALING WITH A CIVILIAN GROUP, I SEE THEIR VULNERABILITY AS 
RESPONSIVENESS AND LACK OF TRAINING. I INTEND TO EXPLOIT THIS BY LANDING EARLY 
IN THE MORNING AND MOVING TO THE OBJECTIVE QUICKLY BEFORE THE GENERAL 
POPULACE IS AWAKE. 2. ENDSTATE. I SEE OUR ENDSTATE AS ATF OBJECTIVE A SECURED 
AND I N CONTROL OF CTF 175. </OrganisationActionTaskAssociation.intentText> 

<OrganisationActionTaskAssociation.effectiveTirme >54000</OrganisationActionTaskAssociation.effecti 
veTime > 

<OrganisationActionTaskAssociation.effectiveDate>36518 </OrganisationActionTaskAssociation.effecti 
veDate> 

<OrganisationActionTaskAssociation.categoryCode>PROVDR</OrganisationActionTaskAssociation.cat 

egoryCode> 

<ActionTask. id >999990000 l</ActionTask. id > 

-Organisation, id >5 55550001</ Organisation, id > 

<updateSequenceNumber>777771234567890</updateSequenceNumber> 
cownerl d>81234567890</ownerl d> 

</OrganisationActionTaskAssociation> 

<j Organisation ActionTaskAssociationTable > 

<J GH4Complete> 
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APPENDIX M. XML TO XML STYLESHEET 


A. INTRODUCTION 

In order for the operation order in Appendix J to become the operation order in Appendix L, and consequently compliant with 
the Generic Hub (GH), an XSL stylesheet is applied to change its format. Specifically, XSLT is used to transform one XML 
document into another. Once “linked”, operation orders can be produced with the improved XML-MTF schema (Appendix I), 
transformed into orders compliant with the GH schema (Appendix K) and read into the database. As soon as autogeneration of the 3D 
scene is functional, the GH database can feed and update the information in the scene; in other words the data flow and transformation 
works both ways. This stylesheet is created by Doug Horner and is still a work in progress. 

B. STYLESHEET 

<?xml version = "1.0" encoding="UTF-8"?> 

<xsl: stylesheet version ="1.0" xmIns: xsl="http:// www.w3.org/1999/XSL/Transform"> 

<xsl:output method="xml" indent ="no"/> 

<xsl:template match=7"> 

<xsl: pa ram name- 1 1 nitialFeatureNumber" select ="11 1110000 "></ xsl: param> 

<Obj ectl temT a ble > 

<xsl: for-each select ="/ Order/GeneraITextl nformation/Tasks/Organization/MarineExpeditionaryUnit "> 
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<xsl:call-template name -'AssignOR"/ > 

</xsl:for-each> 

<xsl:for-each 

select-'/ Order/GeneraITextl nformation/Tasks/Organization/MarineExpeditionaryUnit/BattalionLandingTeam" > 

<xsl:call-template name =" AssignOR"/ > 

</xsl:for-each> 

<xsl:for-each 

select- 1 / Order/ Genera ITextl nformation/Tasks/Organization/MarineExpeditionaryUnit/BattalionLandingTeam/Company "> 

<xsl:call-template name =" AssignOR"/ > 

</xsl:for-each> 

<xsl:for-each 

select- 1 / Order/ Genera ITextl nformation/Tasks/ Orga n ization/Ma rineExpedition ary Unit/ Battalion La ndingTeam/Company/Platoon" 
> 

<xsl:call-template name =" AssignOR"/ > 

</xsl:for-each> 

<xsl: for-each select ="/ Order/ Genera ITextl nformation/Tasks/ ExecutionTimelineAnd Movement/1 nsertion"> 

<xsl:call-template name ="AssignFE"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/ Genera ITextl nform ation/Tasks/ExecutionTimelineAnd Movement/1 nfiltration"> 

<xsl:call-template name ="AssignFE"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/ Genera ITextl nformation/Tasks/ExecutionTimelineAndMovement/ActionsAtTheObjective "> 
<xsl:call-template name ="AssignFE"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/ Genera ITextl nform ation/Tasks/ ExecutionTi melineAnd Movement/Exfil"> 

<xsl:call-template name ="AssignFE"/> 

</xsl:for-each> 
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<xsl:for-each select ="/ Order/GeneraITextlnformation/Tasks/ExecutionTimelineAnd Movement/Extraction'^ 
<xsl:call-template name ="AssignFE"/> 

</xsl:for-each> 

</Obj ectltemTable > 

<ObjectTypeTable> 


<xsl: if test ="/ Order/ Genera ITextl nformation/Tasks/Organization/MarineExpeditionaryUnit "> 

<xsl: cal I-tern plate name ="AssignObjectTypeNumber"/> 

</ xsl: if > 

<xsl:for-each 

select-'/ Order/ Genera ITextl nformation/Tasks/Organization/MarineExpeditionary Unit/ Battalion La ndingTeam" > 

<xsl: cal I-tern plate name ="AssignObjectTypeNumber"/> 

</xsl:for-each> 

<xsl:for-each 

select-'/ Order/ Genera ITextl nformation/Tasks/Organization/MarineExpeditionary Unit/ Battalion La ndingTeam/Company "> 

<xsl:call-template name ="AssignObjectTypeNumber"/> 

</xsl:for-each> 

<xsl:for-each 

select-'/ Order/ Genera ITextl nformation/Tasks/Organization/MarineExpedition ary Unit/ Battalion La ndingTeam/Company/Platoon" 
> 

<xsl: cal I-template name ="AssignObjectTypeNumber"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/ Genera ITextl nformation/Tasks/ExecutionTimelineAnd Movement/1 nsertion"> 

<xsl: cal I-template name ="AssignObjectTypeNumber"/> 

</xsl:for-each> 

</ObjectTypeTable> 

<OrganisationTable > 
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<xsl:for-each select ="/ Order/OrderReference/OrderOriginatorAndOrNumber/MilitaryCommandAuthority"> 
<xsl: call-template name - 'Organisation"/ > 

</xsl:for-each> 


<xsl: for-each select ="/ Order/GeneraITextl nformation/Tasks/Organization/MarineExpeditionaryUnit "> 

<xsl: cal I-tern plate name - 'Organisation "/> 

</xsl:for-each> 

<xsl:for-each 

select-'/ Order/ Genera ITextl nformation/Tasks/Organization/MarineExpeditionaryUnit/BattalionLandingTeam" > 

<xsl: call-template name - 'Organisation"/ > 

</xsl:for-each> 

<xsl:for-each 

select-'/ Order/ Genera ITextl nformation/Tasks/Organization/MarineExpeditionaryUnit/BattalionLandingTeam/Company "> 

<xsl: call-template name - 'Organisation"/ > 

</xsl:for-each> 

<xsl:for-each 

select-'/ Order/ Genera ITextl nformation/Tasks/ Organ ization/MarineExpeditionary Unit/ Battalion Land ingTeam/Company/ Platoon" 
> 

<xsl: call-template name ="Organisation"/ > 

</xsl:for-each> 

</OrganisationTable > 

<ReferenceTable > 

<xsl: call-template name =" References"/ > 

</ ReferenceTable > 

<ReportingDataTable > 

<ReportingData> 

<Reporting Data, id >22220001 </ Reporting Data, id > 
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<ReportingData.timingCategoryCode>RDABST </ Reporting Data. timingCategoryCode> 
<ReportingData.reportingTime >54000 </ Reporting Data. reportingTi me > 

<ReportingData, reportingDate>3 6518</ ReportingData.reportingDate> 
<ReportingData.credibilityCode>TRSTED</ ReportingData.credibilityCode> 

<ReportingData.countingl ndicatorCode>NO</ ReportingData.countingl ndicatorCode> 

<ReportingData.confirmation! ndicatorCode>NO</ ReportingData.confirmation! ndicatorCode> 
<ReportingData.categoryCode>REP</ Reporting Data. categoryCode> 

<Reference. id xxsl: value- of 

select-'/ Order/Message!dentification/MessageSerialNumber/@referenceldNumber"/></ Reference.id > 

<ReportingOrganisation. id xxsl: value-of 

select- 1 / Order/GeneraITextl nformation/Tasks/Organization/MarineExpeditionaryUnit/@objectl teml dNumber"/ ></ ReportingOrg 
anisation.id> 

<updateSequenceNumber>777771234567890</updateSequenceNumber> 

<o wnerl d >812 34567 890 </ownerld> 

</ ReportingData> 

</ ReportingDataTable > 

<ObjectltemTypeTable> 

<xsl: for- each select ="/ Order/ Genera ITextl nformation/Tasks/Organization/MarineExpeditionaryUnit "> 

<xsl:call-template name ="AssignObjectltemTypelndex"/> 

</xsl:for-each> 

<xsl:for-each 

select- 1 / Order/ Genera ITextl nformation/Tasks/ Organ ization/MarineExped it ionaryU nit/ Battalion La ndingTeam" > 

<xsl:call-template name ="AssignObjectltemTypelndex"/> 

</xsl:for-each> 

<xsl:for-each 

select-'/ Order/ Genera ITextl nformation/Tasks/Organization/MarineExpeditionary Unit/Battalion La ndingTeam/Company "> 

<xsl:call-template name="AssignObjectltemTypelndex"/> 

</xsl:for-each> 
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<xsl:for-each 

select-'/ Order/ Genera ITextl nformation/Tasks/ Orga n ization/Ma rineExpedition ary Unit/ Battalion La ndingTeam/Company/Platoon" 
> 

<xsl:call-template name -'AssignObjectltemTypelndex"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/ Genera ITextl nformation/Tasks/ExecutionTimelineAndMovement/l nsertion"> 

<xsl: cal I-tern plate name =" AssignObjectltemTypel ndex"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/ Genera ITextl nformation/Tasks/ExecutionTimelineAndMovement/l nfiltration"> 

<xsl:call-template name =" AssignObjectltemTypelndex"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/ Genera ITextl nformation/Tasks/ExecutionTimelineAndMovement/ActionsAtTheObjective '"> 
<xsl: call-template name -'AssignObjectl temTypel ndex"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/Genera ITextl nformation/Tasks/ ExecutionTimelineAnd Movement/ Exfil"> 

<xsl:call-template name =" AssignObjectltemTypelndex"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/Genera ITextl nformation/Tasks/ExecutionTimelineAnd Movement/Extraction "> 

<xsl:call-template name =" AssignObjectltemTypelndex"/> 

</xsl:for-each> 

</Obj ectltemTypeTable > 

<FeatureTable> 

<xsl: for-each select ="/ Order/Genera ITextl nformation/Tasks/ExecutionTimelineAnd Movement/1 nsertion"> 

<xsl:call-template name= FeatureTableldNumber"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/ Genera ITextl nform ation/Tasks/ExecutionTi melineAnd Movement/1 nfiltration"> 
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<xsl:call-template name -'FeatureTableldNumber"/ > 

</xsl:for-each> 

<xsl: for-each select ="/ Order/GeneraITextl nformation/Tasks/ExecutionTimelineAndMovement/ActionsAtTheObjective"> 
<xsl:call-template name -'FeatureTableldNumber"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/Genera ITextl nformation/Tasks/ExecutionTimelineAndMovement/Exfil"> 

<xsl:call-template name =" FeatureTableldNumber"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/ Genera ITextl nformation/Tasks/ExecutionTimelineAnd Movement/Extraction'^ 

<xsl:call-template name =" FeatureTableldNumber"/> 

</xsl:for-each> 

</FeatureTable> 

<LocationTable > 

<xsl: for-each select ="/ Order/Genera ITextl nformation/Tasks/ExecutionTimelineAndMovement/l nsertion"> 

<xsl: cal I-tern plate name -'LocationTablel dN umber"/ > 

</xsl:for-each> 

<xsl: for-each select ="/ Order/ Genera ITextl nfo rmation/Tasks/ExecutionTimelineAnd Movement/1 nfiltration"> 

<xsl: call-template name =" LocationTablel dN umber"/ > 

</xsl:for-each> 

<xsl: for- each select ="/ Order/Genera ITextl nformation/Tasks/ExecutionTimelineAndMovement/ActionsAtTheObjective"> 
<xsl: call-template name =" LocationTablel dN umber"/ > 

</xsl:for-each> 

<xsl: for-each select ="/ Order/Genera ITextl nformation/Tasks/ExecutionTimelineAnd Movement/Exfil"> 

<xsl: call-template name =" LocationTablel dN umber"/ > 

</xsl:for-each> 
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<xsl:for-each select ="/ Order/Genera ITextl nform ation/Tasks/ExecutionTi melineAnd Movement/Extraction 1 ^ 

<xsl:call-template name -'LocationTableldNumber"/ > 

</xsl:for-each> 

</LocationTable > 

<FeatureLocationTable > 

<xsl: for-each select ="/ Order/ Genera ITextl nform ation/Tasks/ExecutionTimelineAnd Movement/1 nsertion"> 

<xsl: cal I-tern plate name ="FeatureLocationTableNumber"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/ Genera ITextl nform ation/Tasks/ ExecutionTi melineAnd Movement/1 nfiltration"> 

<xsl:call-template name ="FeatureLocationTableNumber"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/ Genera ITextl nformation/Tasks/ExecutionTimelineAndMovement/ActionsAtTheObjective"> 
<xsl:call-template name ="FeatureLocationTableNumber"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/Genera ITextl nform ation/Tasks/ExecutionTi melineAnd Movement/Exfi I" > 

<xsl:call-template name ="FeatureLocationTableNumber"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/Genera ITextl nform ation/Tasks/ExecutionTi melineAnd Movement/Extraction 1 ^ 

<xsl:call-template name ="FeatureLocationTableNumber"/> 

</xsl:for-each> 

</FeatureLocationTable > 

<PointTable > 

<xsl: for-each select ="/ Order/ Genera ITextl nform ation/Tasks/ ExecutionTi melineAndMovement/1 nsertion"> 

<xsl: cal I-template name -'PointTablel dN umber"/ > 

</xsl:for-each> 


196 


<xsl: for-each select ="/ Order/GeneraITextl nformation/Tasks/ ExecutionTimelineAndMovement/1 nfiltration"> 

<xsl:call-template name =' 'PointTableldNumber"/ > 

</xsl:for-each> 

<xsl: for- each select ="/ Order/ Genera ITextl nform ation/Tasks/ ExecutionTi melineAnd Move ment/ActionsAtTheObjective"> 
<xsl: call-template name =" PointTablel dN umber"/ > 

</xsl:for-each> 

<xsl: for-each select ="/ Order/ Genera ITextl nform ation/Tasks/ExecutionTi melineAnd Mo vement/Exfi I" > 

<xsl: call-template name =" PointTablel dN umber"/ > 

</xsl:for-each> 

<xsl: for-each select ="/ Order/ Genera ITextl nform ation/Tasks/ExecutionTi melineAnd Movement/Extraction 1 ^ 

<xsl: call-template name =" PointTablel dN umber"/ > 

</xsl:for-each> 

</PointTable > 

<AbsolutePointTable > 

<xsl: for-each select ="/ Order/Genera ITextl nform ation/Tasks/ ExecutionTi melineAnd Movement/1 nsertion"> 

<xsl: cal I-template name ="AbsolutePointTablel dNumber"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/ Genera ITextl nform ation/Tasks/ExecutionTi melineAnd Movement/1 nfiltration"> 

<xsl: call-template name =" Absolute PointTablel d Number"/ > 

</xsl:for-each> 

<xsl: for-each select ="/ Order/Genera ITextl nformation/Tasks/ExecutionTimelineAndMovement/ActionsAtTheObjective"> 
<xsl: call-template name =" Absolute PointTablel d Number"/ > 

</xsl:for-each> 

<xsl: for-each select ="/ Order/ Genera ITextl nform ation/Tasks/ExecutionTi melineAnd Mo vement/Exfi I" > 

<xsl: call-template name =" Absolute PointTablel d Number"/ > 
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</xsl:for-each> 


<xsl: for-each select ="/ Order/GeneraITextl nform ation/Tasks/ExecutionTi melineAnd Movement/Extraction'^ 

<xsl: call-template name - 'AbsolutePointTablel dNumber"/ > 

</xsl:for-each> 

</AbsolutePointTable > 

<ActionTable > 

<xsl: for-each select ="/ Order/ Genera ITextl nformation/Tasks/ExecutionTimelineAndMovement/l nsertion"> 

<xsl: cal I-tern plate name -'Act ion I dNumber"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/ Genera ITextl nform ation/Tasks/ ExecutionTi melineAnd Movement/1 nfiltration"> 

<xsl: call-template name - 'ActionI dNumber"/> 

</xsl:for-each> 

<xsl: for- each select ="/ Order/Genera ITextl nform ation/Tasks/ExecutionTi melineAnd Movement/ActionsAtTheObjective 
<xsl: call-template name -'Action I dN umber"/ > 

</xsl:for-each> 

<xsl: for-each select ="/ Order/Genera ITextl nform ation/Tasks/ ExecutionTi melineAnd Mo vement/Exfil"> 

<xsl: call-template name =" Action I dNumber"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/ Genera ITextl nform ation/Tasks/ExecutionTi melineAnd Movement/Extraction'^ 

<xsl: call-template name - 'ActionI dN umber"/ > 

</xsl:for-each> 

</ActionTable > 

<CandidateTargetListTable > 

<CandidateTargetList > 

<CandidateTargetList.id>6566</CandidateTargetList.id> 


> 


198 


<CandidateTargetList.name >The Pendleton AF <CandidateTargetList.name > 

<ReportingData. id >22220001 </ Reporting Data, id > 

<u pdateSeq uenceN u mber>77777 1234567890c/ updateSequencel\lumber> 
cownerl d >812 34567890 </ownerl d> 

</CandidateTargetList > 

</CandidateTargetListTable > 

cCandidateTargetDetailTable > 

cxsl: for-each select ="/ Order/GeneraITextl nformation/Tasks/ExecutionTimelineAndMovement/l nsertion"> 
cxsl: call-template name ="CandidateTargetlndexNumber"/> 

</xsl:for-each> 

cxsl: for-each select ="/ Order/ Genera ITextl nform ation/Tasks/ExecutionTimelineAnd Movement/1 nfiltration"> 

cxsl: call-template name ="CandidateTargetlndexNumber"/> 

c/xsl:for-each> 

cxsl: for-each select ="/ Order/ Genera ITextl nform ation/Tasks/ExecutionTimelineAndMovement/ActionsAtTheObjective"> 

cxsl: call-template name -'CandidateTargetlndexNumber"/> 

c/xsl:for-each> 

cxsl: for-each select ="/ Order/ Genera ITextl nformation/Tasks/ExecutionTimelineAndMovement/Exfil"> 

cxsl: call-template name ="CandidateTargetlndexNumber"/> 

c/xsl:for-each> 

cxsl: for-each select ="/ Order/ Genera ITextl nform ation/Tasks/ExecutionTimelineAnd Movement/ Extraction 1 ^ 

cxsl:call-template name ="CandidateTargetlndexNumber"/> 

c/xsl:for-each> 


c/CandidateTargetDetailTable > 
cCandidateTargetDetailltemTable > 

cxsl: for-each select ="/ Order/ Genera ITextl nformation/Tasks/ExecutionTimelineAndMovement/l nsertion"> 
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<xsl:call-template name ="TargetDetailltemNumber"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/GeneraITextl nformation/Tasks/ExecutionTimelineAndMovement/1 nfiltration"> 

<xsl:call-template name ="TargetDetailltemNumber"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/Genera ITextl nformation/Tasks/ExecutionTimelineAndMovement/ActionsAtTheObjective"> 
<xsl:call-template name ="TargetDetailltemNumber'7> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/ Genera ITextl nformation/Tasks/ExecutionTimelineAndMovement/ExfH"> 

<xsl:call-template name ="TargetDetailltemNumber'7> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/ Genera IT extl nformation/Tasks/ExecutionTimelineAnd Movement/ Extraction 1 ^ 

<xsl:call-template name ="TargetDetailltemNumber'7> 

</xsl:for-each> 

</CandidateTargetDetaill temTable > 

<ActionTaskTable > 

<xsl: for-each select ="/ Order/ Genera ITextl nformation/Tasks/ExecutionTimelineAnd Movement/1 nsertion"> 

<xsl:call-template name ="ActionTaskReferenceTable'7> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/ Genera ITextl nform ation/Tasks/ExecutionTimelineAnd Movement/1 nfiltration"> 

<xsl:call-template name ="ActionTaskReferenceTable'7> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/Genera ITextl nformation/Tasks/ExecutionTimelineAndMovement/ActionsAtTheObjective"> 
<xsl:call-template name ="ActionTaskReferenceTable'7> 

</xsl:for-each> 
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<xsl: for- each select ="/ Order/GeneralTextl nformation/Tasks/ExecutionTimelineAndMovement/Exfil"> 

<xsl:call-template name ="ActionTaskReferenceTable"/> 

</xsl:for-each> 

<xsl:for-each select ="/ Order/GeneralTextlnform ation/Tasks/ExecutionTi melineAnd Movement/Extraction'^ 
<xsl:call-template name ="ActionTaskReferenceTable"/> 

</xsl:for-each> 


</ActionTaskTable > 

<ActionFunctionalAssociationTable > 

<xsl:for-each select ="/ Order/GeneralTextl nformation/Tasks/ExecutionTimelineAndMovement/l nsertion"> 

<xsl:call-template name ="ActionFunctionalAssociationlndexNumber"/> 

</xsl:for-each> 

<xsl:for-each select ="/ Order/GeneralTextl nformation/Tasks/ExecutionTimelineAndMovement/1 nfiltration"> 

<xsl: call-template name -'ActionFunctionalAssociationl ndexNumber"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/GeneralTextl nform ation/Tasks/ExecutionTi melineAnd Movement/ActionsAtTheObjective 
<xsl: call-template name =" ActionFunctionalAssociationl ndexNumber"/> 

</xsl:for-each> 

<xsl:for-each select ="/ Order/GeneralTextlnformation/Tasks/ExecutionTimelineAndMovement/Exfil"> 

<xsl: call-template name =" ActionFunctionalAssociationl ndexNumber"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/GeneralTextl nform ation/Tasks/ExecutionTi melineAnd Movement/Extraction "> 

<xsl:call-template name =" ActionFunctionalAssociationlndexNumber"/> 

</xsl:for-each> 

</ Action Functiona I AssociationTable > 


> 
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<ActionResourceltemTable > 


<xsl: for-each select ="/ Order/GeneraITextl nformation/Tasks/ExecutionTimelineAndMovement/l nsertion"> 

<xsl:call-template name ="ActionResourceltemTablelndex"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/Genera ITextl nform ation/Tasks/ExecutionTimelineAnd Movement/1 nfiltration"> 

<xsl:call-template name -'ActionResourceltemTablelndex"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/ Genera ITextl nformation/Tasks/ExecutionTimelineAndMovement/ActionsAtTheObjective"> 
<xsl:call-template name =" ActionResourceltemTablelndex"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/ Genera ITextl nformation/Tasks/ExecutionTimelineAndMovement/Exfil"> 

<xsl:call-template name =" ActionResourceltemTablelndex"/> 

</xsl:for-each> 

<xsl: for- each select ="/ Order/Genera ITextl nform ation/Tasks/ExecutionTimelineAnd Movement/ Extraction"> 

<xsl:call-template name =" ActionResourceltemTablelndex"/> 

</xsl:for-each> 

</ActionResourcel temTable > 

<ActionResourceltemTable > 

<xsl: for-each select ="/ Order/ Genera ITextl nformation/Tasks/ExecutionTimelineAndMovement/l nsertion"> 

<xsl: call-template name =" Lin king Action I d20bjectl teml dNumber"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/Genera ITextl nformation/Tasks/ExecutionTimelineAnd Movement/1 nfiltration"> 

<xsl: call-template name =" Lin king Action I d20bjectl teml dN umber"/ > 

</xsl:for-each> 

<xsl: for-each select ="/ Order/ Genera ITextl nformation/Tasks/ExecutionTimelineAndMovement/ActionsAtTheObjective"> 
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<xsl: cal I-template name -'Linking Action I d20bjectl teml dNumber"/ > 

</xsl:for-each> 

<xsl:for-each select ="/ Order/GeneraITextl nformation/Tasks/ExecutionTimelineAndMovement/Exfil"> 

<xsl: call-template name =" Lin king Action I d20bjectl teml dNumber"/ > 

</xsl:for-each> 

<xsl: for-each select ="/ Order/Genera ITextl nform ation/Tasks/ExecutionTi melineAnd Movement/Extraction'^ 

<xsl: call-template name =" Lin king Action I d20bjectl teml dNumber"/ > 

</xsl:for-each> 

</ActionResourcel temTable > 

<ActionObjectiveTable > 

<xsl: for-each select ="/ Order/ Genera ITextl nformation/Tasks/ExecutionTimelineAndMovement/l nsertion"> 

<xsl:call-template name ="ActionObjectiveTable"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/Genera ITextl nform ation/Tasks/ ExecutionTi melineAnd Movement/1 nfiltration"> 

<xsl:call-template name ="ActionObjectiveTable"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/ Genera ITextl nformation/Tasks/ExecutionTimelineAndMovement/ActionsAtTheObjective"> 
<xsl:call-template name ="ActionObjectiveTable"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/Genera ITextl nform ation/Tasks/ ExecutionTi melineAnd Mo vement/Exfil"> 

<xsl:call-template name ="ActionObjectiveTable"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/Genera ITextl nform ation/Tasks/ ExecutionTi melineAndMovement/Extraction'^ 

<xsl:call-template name ="ActionObjectiveTable"/> 

</xsl:for-each> 
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</ActionObjectiveTable > 

<ActionObjectivel temTable > 

<xsl: for- each select ="/ Order/GeneraITextl nformation/Tasks/ExecutionTimelineAndMovement/l nsertion"> 

<xsl: call-template name ="ActionObjectiveltemCrossReferenceTable"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/ Genera ITextl nform ation/Tasks/ExecutionTi melineAnd Movement/1 nfiltration"> 

<xsl: call-template name ="ActionObjectiveltemCrossReferenceTable"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/ Genera ITextl nformation/Tasks/ExecutionTimelineAndMovement/ActionsAtTheObjective"> 
<xsl: call-template name ="ActionObjectiveltemCrossReferenceTable"/> 

</xsl:for-each> 

<xsl: for-each select ="/ Order/ Genera ITextl nform ation/Tasks/ExecutionTi melineAnd Movement/Exfil"> 

<xsl: call-template name ="ActionObjectiveltemCrossReferenceTable"/> 

</xsl:for-each> 

<xsl: for- each select ="/ Order/Genera ITextl nform ation/Tasks/ExecutionTi melineAnd Movement/Extraction 1 ^ 

<xsl: call-template name -'ActionObjectiveltemCrossReferenceTable"/> 

</xsl:for-each> 

</ ActionObjectivel temTable > 

<ContextTable > 

<xsl: for-each select ="/ Order/Genera ITextl nformation/GentextTextl ndicator"> 

<xsl:call-template name -'ContextTableNumbers "/> 

</xsl:for-each> 

</ContextTable> 

<ActionContextTable > 
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<xsl: for-each select ="/ Order/GeneraITextl nformation/GentextTextl ndicator"> 

<xsl:call-template name ="ActionContextReference'7> 

</xsl:for-each> 

</ActionContextTable > 

<ContextAssessmentTable > 

<xsl: if test="/Order/GeneralTextl nformation[@name = 'Situation'] "> 

<ContextAssessment > 

<ContextAssessment.index>1001</ContextAssessment.index> 

<ContextAssessment.effectiveTime ></ContextAssessment.effectiveTime > 
<ContextAssessment.effectiveDatex/ContextAssessment.effectiveDate> 

<ContextAssessment.text xxsl: value-of select ="/ Order/ Genera ITextl nformation[@name 

'Situation']/FreeText "/> 

</ContextAssessment.text > 

<Context.id> 

<xsl: value-of select ="/ Order/ Genera ITextl nformation[@name 

'Situation']/GentextTextl ndicator/@contextl d"/> 

</Context.id> 

<ContextAssessingOrganisation.id> 

<xsl: value-of select="/Order/Exerciseldentification/@actionldNumber"/ > 
</ContextAssessingOrganisation.id> 

<updateSequenceNumber>777771234567890</updateSequenceNumber> 

<o wnerl d >812 34567 890 </ownerld> 

</ContextAssessment > 

</xsl: if > 

<xsl: if test="/Order/GeneralTextl nformation[@name = 'Mission'] "> 

<ContextAssessment > 

<ContextAssessment.index>1001</ContextAssessment.index> 
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<ContextAssessment.effectiveTime ></ContextAssessment.effectiveTime > 
<ContextAssessment.effectiveDatex/ContextAssessment.effectiveDate> 

<ContextAssessment.text xxsl: value-of select="/Order/GeneralTextl nformation[@name 

Mission']/FreeText"/> 

</ContextAssessment.text > 

<Context.id> 

<xsl: value-of select="/Order/GeneralTextl nformation[@name = 1 Mission']/GentextTextl ndicator/@contextl d"/ 
</ Context, id > 

<ContextAssessingOrganisation.id> 

<xsl:value-of select="/Order/Exerciseldentification/@actionldNumber"/ > 

</ContextAssessingOrganisation.id> 

<updateSequenceNumber>777771234567890</updateSequenceNumber> 

<ownerl d >81234567890</ownerl d> 

</ContextAssessment > 

</ xsl: if > 

<xsl: if test='70rder/GeneralTextl nformation[@name = 'Execution'] "> 

<ContextAssessment > 

<ContextAssessment.index>1001</ContextAssessment.index> 

<ContextAssessment. effectiveTi me ></ ContextAssessment. effectiveTime > 
<ContextAssessment.effectiveDatex/ContextAssessment.effectiveDate> 

<ContextAssessment.text xxsl: value-of select ="/ Order/Genera ITextl nformation[@name 

Execution']/ FreeText "/ > 

</ContextAssessment.text > 

<Context.id> 

<xsl: value-of select-'/ Order/ Genera ITextl nformation[@name 

Execution']/GentextTextl ndicator/@contextld"/> 

</Context.id> 

<ContextAssessingOrganisation.id> 

<xsl: value-of select="/Order/Exerciseldentification/@actionl dN umber"/ > 

</ContextAssessingOrganisation.id> 

<updateSequenceNumber>777771234567890</updateSequenceNumber> 

<ownerl d >81234567890</ownerl d> 

</ ContextAssessment > 
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</xsl: if> 


<xsl: if test="/Order/GeneralTextl nformation[@name = 'AdminAndLog'] "> 

<ContextAssessment > 

<ContextAssess merit. index>l 00 l</ContextAssessment.index> 

<ContextAssessment.effectiveTirne ></ContextAssessment.effectiveTime > 
<ContextAssessment.effectiveDatex/ContextAssessment.effectiveDate> 

<ContextAssessment.text xxsl: value-of select ="/ Order/GeneraITextl nformation[@name 

'AdminAndLog'l/FreeText "/> 

</ContextAssessment.text > 

<Context.id> 

<xsl: value-of select ="/ Order/ Genera ITextl nformation[@name 

'AdminAndLog'l/GentextTextl ndicator/@contextl d"/> 

</Context.id> 

<ContextAssessingOrganisation.id> 

<xsl: value-of select= , 70rder/Exerciseldentification/@actionldNumber"/ > 
</ContextAssessingOrganisation.id> 

<updateSequenceNumber>777771234567890</updateSequenceNumber> 

<ownerl d >812 34567 890 </ownerl d> 

</ContextAssessment > 

</ xsl: if > 

<xsl: if test="/Order/GeneralTextl nformation[@name = 'AdminAndLog'] "> 

<ContextAssessment > 

<ContextAssessment.index>1001</ContextAssessment.index> 

<ContextAssessment.effectiveTime x/ContextAssessment.effectiveTime > 
<ContextAssessment.effectiveDatex/ContextAssessment.effectiveDate> 

<ContextAssessment.text xxsl: value-of select ="/ Order/ Genera ITextl nformation[@name 

'CommandAndControl'j/FreeText "/> 

</ContextAssessment.text > 

<Context.id> 
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<xsl: value-of sel ect="/ Order/GeneraITextl nformation[@name 

'CommandAndControl'l/GentextTextl ndicator/@contextl d"/> 

</Context.id> 

<ContextAssessingOrganisation.id> 

<xsl: value-of select="/ Order/Exerciseldentification/@actionldNumber"/ > 
</ContextAssessingOrganisation.id> 

<updateSequenceNumber>777771234567890</updateSequenceNumber> 

<o wnerl d >812 34567 890 </ownerld> 

</ContextAssessment > 

</ xsl: if > 

</ContextAssessmentTable > 


</xsl:template> 

<xsl:template name ="AssignOR"> 

<Objectltem> 

<0bjectltern.id xxsl: value-of select="@objectltemldNumber"/></ Objectltem.id> 
<Objectl tern.name > 

<xsl: value-of select="@name "/> 

</Obj ectl tern, name > 

<Objectl tern.categoryCode>OR</Objectl tern. categoryCode> 
<updateSequenceNumber>777771234567890</updateSequenceNumber> 

<o wnerl d >812 34567 890 </o wnerl d> 

</Objectltem> 

</xsl:template> 

<xsl:template name ="AssignFE"> 

<Objectltem> 

<Objectl tern.id xxsl: value-of select="@objectltemldNumber"/></ Objectltem.id> 
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<Objectl tern.name > 

<xsl: value-of select="@name "/> 

</Obj ectl tern, name > 

<Objectl tern.categoryCode>FE</Objectl tern.categoryCode> 
<updateSequenceNumber>777771234567890</updateSequenceNumber> 

<ownerl d>81234567890</ownerl d> 

</Objectl tem> 

</xsl:template> 

<xsl:template name ="AssignObjectTypeNumber"> 

<ObjectType> 

<ObjectType.idxxsl:value-of select ="@objectTypeldNumber"/ ></ ObjectType.id> 
<ObjectType. nationalityCode>US </ObjectType.nationalityCode> 

<ObjectType. name > 

<xsl: value-of select="@name "/> 

</ObjectType.name > 

ObjectType.dummyl ndicatorCode>NO</ ObjectType.dummyl ndicatorCode> 
<ObjectType.categoryCode>OR</Obj ectType.categoryCode> 
<updateSequenceNumber>777771234567890</updateSequenceNumber> 

<o wnerl d >812 34567 890 </ownerld> 

</ObjectType> 

</xsl:template> 


<xs I:template name ="Organisation "> 

<Organisation> 

Organisation. nicknameN a me xxsl: value-of select="@name"/></ Organisation. nicknameNa me > 
<0 rganisation. categoryCode >UN</ Organ isation.categoryCode> 

Organisation, id xxsl: value-of select ="@obj ectl tern I dN umber"/ ></ Organisation, id > 
<updateSequenceNumber>777771234567890</updateSequenceNumber> 

<o wnerl d >812 34567 890 </o wnerl d> 

</Organisation > 

</xsl:template> 


209 


<xsl: template name -'References'^ 


<Reference> 

<Reference. id xxsl: value- of 

sel ect="/ Order/Messagel dentification/MessageSerialNumber/@referencel dNumber"/ ></ Reference, id > 
<Reference.transmittalTypeCode>TELEX</ Reference. transmittalTypeCode> 

<Reference.sourceText xxsl: value- of 

sel ect="/ Order/Messagel dentification/Originator/MessageClassification"/x/ Reference.sourceText > 
<Reference.securityClassificationCode xxsl: value-of 

sel ect="/ Order/Messagel dentification/MessageSerialNumber/@referencel dN umber"/ ></ Reference. securityClassificationCode> 
<Reference. identificationText >Exercise: <xsl: value- of select ="/ Order/Exercisel dentification/@setid "/ >; Exercise 
Nickname: <xsl:value-of select="/Order/Exerciseldentification/ExerciseNickname"/>; Messageld: <xsl:value-of 

sel ect="/ Order/Messagel dentification/@setid"/>; Msg Format: <xsl: value- of 

sel ect="/ Order/Messagel dentificationMessageTextFormatl dentifier"/>; SerialNumber: <xsl: value-of 

sel ect="/ Order/ Messagel dentification/MessageSerialNumber"/>; OrderType: <xsl: value-of 

select="/Order/TypeOfOrder/@setid"/>; Plan Type; <xsl: value-of select="/Order/TypeOfOrder/TypeOfPlanOrder"/>; 
Authority: <xsl:value-of select="/Order/OrderReference/OrderOriginatorAndOrNumber/MilitaryCommandAuthority"/>; 

OpOrderNr: <xsl:value-of select ="/Order/OrderReferenee/OrderOriginatorAndOrNumber/OperationOrderNumber"/> 

</ Reference. identificationText > 

<Reference.formatCodexxsl: value- of 

select="/Order/Messagel dentification/MessageFormat "/></ Reference.formatCode> 

<updateSequenceNumber>777771234567890</updateSequenceNumber> 

<ownerl d >812 34567 890 </ownerl d> 

</ Reference> 

</xsl:template> 

<xsl:template name ="AssignObjectltemTypelndex"> 

<Obj ectl temTy pe > 

cObjectl temType. index>3 33 00001 <Objectl temType.index> 

<Obj ectl tern, id xxsl: value-of select="@obj ectl tern I dN umber"/ ></ Obj ectl tern, id > 
cObjectType. id xxsl: value-of select="@objectTypel dNumber"/x/ ObjectType.id> 
<ReportingData.id>22220001</ Reporting Data, id > 

<u pdateSeq uenceN u mber>77777 1234567890c/ updateSequenceNumber> 
cownerl d >812 34567 890 </ownerl d> 
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</ObjectltemType> 

</xsl:template> 

<xs I template name ="FeatureTablel dNumber"> 

<Feature> 

<Featu re. categoryCode >CF< Feature. categoryCode> 

<Feature. id xxsl: value- of select ="@objectl tern I d Number"/ ></ Feature. id> 
<u pdateSeq uenceN u mber>77777 1234567890 c/ updateSequenceNumber> 
cownerl d >812 34567 890 </ownerl d> 

</ Feature > 

</xsl:template> 

cxsLtemplate name ="LocationTableldNumber"> 
cLocation > 

cLocation. id xxsl: value-of select="@locationl dN umber"/ ></ Location, id > 
cLocation. categoryCode>PT </ Location. categoryCode> 
cu pdateSeq uenceN u mber>77777 1234567890 c/ u pdateSeq uenceN umber> 
cownerld>81234567890c/ownerld> 
c/ Location > 

c/xsl:template> 

cxs I: template name - 'FeatureLocationTableNumber" > 

cFeatureLocation > 

cFeatureLocation.index> 

cxsl: value-of select="@featureLocationl ndexNumber"/> 

</ Featu reLocation.index> 

cFeatureLocation.accuracyQuantity>Oc/FeatureLocation.accuracyQuantity> 
cLocation. id > cxsl: value-of select="@locationl dN umber"/ >c/ Location, id > 
cFeature.id > cxsl:value-of select ="@obj ectl teml d Number"/ >c/ Feature. id> 
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<ReportingData. id >22220002 </ Reporting Data, id > 

<u pdateSeq uenceN u mber>77777 1234567890c/ updateSequenceNumber> 
cownerl d>81234567890</ownerl d> 

</ FeatureLocation > 

</xsl:template> 

cxsl:template name ="PointTableldNumber" > 

<Point> 

cPoint. vertical PrecisionCode >10 Me/ Point, vertical PrecisionCode> 
<Point.horizontalPrecisionCode>10M</Point.horizontalPrecisionCode> 
<Point.categoryCode>ABS </Point.categoryCode> 

<Point.id > cxsl: value-of select ="@locationI dNumber"/>c/ Point.id > 
cu pdateSeq uenceN u mber>77777 1234567890c/ u pdateSeq uenceN umber> 
cownerl d >812 34567 890 c/ ownerl d> 
c/ Point > 
c/xsl:template> 

cxsl:template name ="AbsolutePointTableldNumber"> 
cAbsolutePoint> 

cAbsolutePoint.longitudeCoordinate> 
cxsl:value-of select="@longitude"/> 
c/AbsolutePoint.longitudeCoordinate> 
cAbsolutePoint.latitudeCoordinate> 
cxsl: value-of select="@latitude"/ > 
c/AbsolutePoint.latitudeCoordinate> 

cAbsolutePoint.elevationCategoryCode>LOCc/AbsolutePoint.elevationCategoryCode> 
cAbsolutePoint.id > cxsl: value-of select="@locationl dNumber"/>c/ AbsolutePoint.id> 
cu pdateSeq uenceN u mber>77777 1234567890c/ u pdateSeq uenceN umber> 
cownerl d >812 34567 890 c/ ownerl d> 
c/AbsolutePoint > 


c/xsl:template> 
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<xs I:template name ="Actionldl\lumber"> 

<Action > 

<Action.idxxsl: value-of select ="@actionldNumber"/ ></ Action.id > 

<Action.name xxsl: value- of select ="@actionDescription "/></ Action.name > 

<A ction.categoryCode>ACTTA</ Action. categoryCode> 
<updateSequenceNumber>777771234567890</updateSequenceNumber> 

<ownerl d >812 34567 890 </ownerl d> 

</ Action > 

</xsl:template> 

<xsl:template name ="CandidateTargetl ndexNumber"> 

<CandidateTargetDetail> 

<CandidateTa rgetDetail.index> 

<xsl: value-of select="@candidateTargetDetaill ndexNumber"/> 

</CandidateTargetDetail.index> 

<CandidateTargetDetail.schemeCode>SITENR</CandidateTargetDetail.schemeCode> 
<CandidateTargetDetail.priorityQuantity>l </CandidateTargetDetail.priorityQuantity> 

<CandidateTargetDetail.labelText/ > 

<CandidateTargetDetail.focusTypeCode>NOS</CandidateTargetDetail.focusTypeCode> 

<Ca nd idateTa rgetDeta i l.discriminatorCode>CTD ITM </ Cand idateTa rgetDetail.discriminatorCode> 
<Ca nd idateTa rgetList. id > 

<xsl: value-of 

sel ect="/ Order/ Genera ITextl nformation/Coordinating I nstructions/MissionObjectiveLocation/@targetl dN umber"/ > 
</ Cand idateTa rgetList. id > 

<u pdateSeq uenceN u mber>77777 1234567890 c/ updateSequenceNumber> 

<o wnerl d >812 34567 890 </ownerld> 

</CandidateTargetDetail> 

</xsl:template> 

<xsl:template name ="TargetDetailltemNumber"> 
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<CandidateTargetDetaill tem> 

<CandidateTa rgetDetail.index> 

<xsl: value-of select="@candidateTargetDetaill ndexNumber"/> 

</CandidateTargetDetail.index> 

<CandidateTargetList. id > 

<xsl: value-of 

select-'/ Order/ Genera ITextl nformation/Coord mating I nstructions/MissionObjectiveLocation/@targetl dN umber"/ > 
</CandidateTargetList.id> 

<Objectltem.id xxsl: value-of select="@objectltemldNumber"/></ Objectltem.id> 

<updateSequenceNumber>777771234567890</updateSequenceNumber> 

<ownerld>81234567890</ownerld> 

</CandidateTa rgetDetaill tem> 

</xsl:template> 

<xs I:template name ="ActionTaskReferenceTable "> 

<ActionTask> 

<ActionTask.plannedEndTime ></ActionTask.plannedEndTime > 

<ActionTask.minimumDuration>0 </ActionTask. minimum Du ration > 
<ActionTask.estimatedDuration>0</ActionTask.estimatedDuration> 

<ActionTask. maximum Du ration >0</ ActionTask. maximum Duration > 
<ActionTask.plannedStartDatexxsl: value-of select="@j u Man Date"/ > 

</ ActionTask. plannedStartDate> 

<ActionTask.plannedStartTime xxsl: value-of select ="@startTimel nSecondsPerDay "/> 

</ ActionTask.plannedStartTime > 

<A ctionTask. sta rtPrecisionCode >HR</ ActionTask. startPrecisionCode> 
<ActionTask.categoryCode>ORD</ActionTask. categoryCode> 

<ActionTask. planned End Datex/ActionTask. plannedEndDate> 

<A ctionTask. end PrecisionCode >HR</ ActionTask. end Precision Code > 
<ActionTask.endQualifierCode>NLT </ ActionTask. endQu a lifierCode> 

<ActionTask.priorityCode>l </ActionTask.priorityCode> 

<ActionTask.verbPhraseCode xxsl: value-of select="@action"/x/ ActionTask.verbPhraseCode> 
<ActionTask.startQualifierCode>NLT <J ActionTask. sta rtQua I ifierCode> 
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<ActionTask.idxxsl: value-of select ="@actionIdNumber"/ ></ ActionTask.id> 

<Ca nd idateTa rgetList. id xxsl: value- of 

select- 1 / Order/ Genera ITextl nformation/Coord mating I nstructions/MissionObjectiveLocation/@targetl dN umber"/ x/Cand idateTa 
rgetList. id > 

<u pdateSeq uenceN u mber>77777 1234567890c/ updateSequenceNumber> 

<o wnerl d >812 34567 890 </ownerld> 

</ActionTask> 

</xsl:template> 

cxshtemplate name ="ActionFunctionalAssociationlndexNumber"> 
cAction Functional Association > 

cActionFunctiona I Association.index>33 12345 00001 </ Action Fu nctiona I Association. index> 
cAction Functiona I Association.categoryCode>HS Ac/ Action Functional Association. categoryCode> 
cObjectAction.id> 

cxsl: value-of select="/Order/Exerciseldentification/@actionl dN umber"/ > 
c/ObjectAction.id> 

cSubjectAction.id > cxsl: value-of select="@actionldNumber"/x/SubjectAction.id> 
cu pdateS equenceN u mber>77777 1234567890c/ u pdateSeq uenceN umber> 
co wnerl d >812 34567 890 c/ o wnerl d> 

</ ActionFunctionalAssociation > 

c/xsl:template> 

cxshtemplate name ="ActionResourceltemTablel ndex"> 
cAction Resource> 

cAction Resource.index>33 12 34560001c/ Act ion Resource. index> 

cA ction Resource, qua lifierCode>AUTHc/ Action Resource, qua I if ierCode> 

cActionResource.criticalityl ndicatorCode>YES c/ActionResource.criticalityl ndicatorCode> 

cAction Resource. categoryCode>RI </ Action Resource.categoryCode> 

cAction. id > cxsl: value-of select ="@actionl dN umber"/ ></ Action, id > 

cAuthorisingOrganisation.id> 
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<xsl: value-of 

select- 1 / Order/ OrderReference/OrderO rig inatorAndOrN umber/ Mi I itaryCommand Authority/@obj ectlteml dN umber"/ > 

</ Authorisi reorganisation, id > 

<updateSequenceNumber>777771234567890</updateSequenceNumber> 

<o wnerl d >812 34567 890 </ownerld> 

</ Action Resource> 

</xsl:template> 

<xsl:template name ="LinkingActionld20bjectlteml dl\lumber"> 

<ActionResourcel tem> 

<ActionResource.index>33 12 34560001 </ Action Resource. index> 

<Action. id xxsl: value-of select ="@action I dN umber"/ ></ Action, id > 

<Obj ectl tern, id xxsl: value-of 

select- 1 / Order/ Genera ITextl nformation/Tasks/ Orga n ization/MarineExpeditionary Unit/ Battalion La ndingTeam/Com pa ny[@na me 
'AAAV Company']/@obj ectl teml dNumber"/x/ Objectl tern, id > 

<u pdateSeq uenceN u mber>77777 1234567890c/ updateSequenceNumber> 

<o wnerl d >812 34567 890 </o wnerl d> 

</ActionResourcel tem> 

</xsl:template> 

cxsktemplate name ="ActionObjectiveTable"> 
cActionObj ective> 

<ActionObjective.index>441 234567 001 </ActionObjective.index> 
cActionObjective. priorityCode>l </ActionObjective.priorityCode> 
<ActionObjective.qualifierCode>AUTH</ActionObjective.qualifierCode> 
cActionObj ective.categoryCode >01 </ActionObjective.categoryCode> 

<Act ion. id xxsl: value-of select ="@action I dN umber"/ ></ Action, id > 

<AuthorisingOrganisation.id> 
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<xsl: value-of 

select- 1 / Order/ OrderReference/OrderO rig inatorAndOrN umber/ Mi I itaryCommand Authority/@obj ectlteml dN umber"/ > 
</ Authorisi reorganisation, id > 

<updateSequenceNumber>777771234567890</updateSequenceNumber> 

<o wnerl d >812 34567 890 </ownerld> 

</ActionObjective> 

</xsl:template> 

<xs I:template name ="ActionObjectiveltemCrossReferenceTable"> 

<ActionObj ectivel tem> 

<ActionObjectivel tem. categoryCode >NOS </ ActionObj ectivel tem. categoryCode> 

<ActionObjective. index>441 234567 001 </ActionObjective.index> 

<Action. id xxsl: value-of select ="@action I dN umber"/ ></ Action, id > 

cObjectltem.id xxsl: value-of select="@objectltemldNumber"/x/ Objectltem.id> 

<CandidateTargetList. id> 

<xsl: value-of 

select-'/ Order/ Genera ITextl nformation/Coordinating I nstructions/MissionObjectiveLocation/@targetl dN umber"/ > 
</CandidateTargetList.id> 

<CandidateTa rgetDetail.indexxxsl: value- of 
select="@candidateTargetDetaill ndexNumber"/x/CandidateTargetDetail.index> 

<u pdateSeq uenceN u mber>77777 1234567890c/ updateSequenceNumber> 

<o wnerl d >812 34567 890 </o wnerl d> 

</ ActionObj ectivel tem> 

</xsl:template> 

cxshtemplate name ="ContextTableNumbers "> 
cContext > 

cContext.idxxsl:value-of select="@contextl d"/></ Context.id > 
cContext.name >cxsl: value-of select- 1 . "/></ Context.name > 
cu pdateSeq uenceN u mber>77777 1234567890c/ u pdateSeq uenceN umber> 
co wnerl d >812 34567 890 c/ o wnerl d> 
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</ Context > 


</xsl:template> 

<xsl: template name ="ActionContextReference"> 

<ActionContext > 

<ActionContext.index>1001</ActionContext.index> 

<ActionContext.categoryCode>DES</ActionContext.categoryCode> 

<Context.id xxsl: value-of select="@contextl d "/></ Context.id > 

<Action.idxxsl: value-of select = , 70rder/Exerciseldentification/@actionldNumber"/> 
</ Action.id> 

<u pdateSeq uenceN u mber>77777 1234567890c/ updateSequencel\lumber> 
cownerl d >812 34567 890 </ownerl d> 

</ActionContext > 

</xsl:template> 


</xsl: stylesheet > 
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APPENDIX N. AMPHIBIOUS-RAID CODE 


A. INTRODUCTION 

This appendix contains scripted code for the amphibious-raid. This code is available at 
http://web.nps.navy.mil/~brutzman/Savage/Scenarios/CampPendletonCalifornia/AmphibiousRaid 

B. AMPHIBIOUS-RAID CODE 

<?xml version="1.0" encoding="UTF-8"?> 

<!DOCTYPE X3D PUBLIC "http://www.web3D.org/TaskGroups/x3d/translation/x3d-compact.dtd" 
"file:///C:/www.web3D.org/TaskGroups/x3d/translation/x3d-compact.dtd"> 

<X3D> 

<head> 

<meta name=' filename' content= ' <AmphibiousRaid.xml> '/> 

<meta name='description' content= 'Amphibious Raid shows an exemplar amphibious raid at Red Beach, Camp 
Pendleton California. It is the primary scenario for the SAVAGE group. '/> 

<meta name='author' content='Don Brutzman, Curtis Blais, Jeff Weekley, Jane Wu, Shane Nicklaus, Mike 
Hunsberger'/> 

cmeta name='created' content='9 April 2001 '/> 
cmeta name=' revised' content='27 July 2001 '/> 

cmeta name='reference' content =' <NpsRedBeachRaidScenario2001May2.html> '/> 
cmeta name='reference' content =' cNpsRedBeachRaidScenario2001May2.ppt> '/> 
cmeta name='image' content=' cHeloPatrolPendletonBackground.png> 7> 
cmeta name='reference' content =' cAmphibiousRaidWithCommunications.xml> '/> 
cmeta name=' warning ' content='Coordinate system axes need to be aligned properly. '/> 
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cmeta name='url' 

content = ' <http://web.nps.navy.mil/~brutzman/Savage/Scenarios/CampPendletonCalifomia/AmphibiousRaid.xml> '/> 
<meta name=' reference' 

content= ' <http://web.nps.navy.mil/~brutzman/Savage/Tools/Animation/WavpointInterpolator.xml> '/> 

<meta name=' generator' content ='X3D-Edit, <http://www.web3D.org/TaskGroups/x3d/translation/README.X3D- 
Edit.html> '/> 

</head> 

<Scene> 


<!-- Prototype and external prototype declarations must precede scene definition --> 

<ExtemProtoDeclare name=' HiddenViewpoint ' 

url=' " ../. ./Tools/Animation/HiddenViewpointPrototype.wrl#HiddenViewpoint 

<../■ ./Tools/Animation/HiddenViewpointPrototype.wrl> " 

'’ http://web.nps.navy.mi1/~brutzman/Savage/Tools/Animation/HiddenViewpointPrototype.wrl#HiddenViewpoint 

<http://web.nps.navv.mil/~brutzman/Savage/Tools/Animation/HiddenViewpointPrototype.wrl> " 

" ■■/■■/Tools/Animation/HiddenViewpointPrototype.xml#HiddenViewpoint 

<■■/. ./Tools/Animation/HiddenViewpointPrototype.xml> " 

" http ://web .nps .navy .mil/~brutzman/S avage/Tools/Animation/Hidde nV ie wpointPrototype .xml#HiddenViewpoint 

<http://web.nps.navy.mil/~bmtzman/Savage/Tools/Animation/HiddenViewpointPrototype.xml> '"> 

<field name= 'position' type='Vector3 Float' vrml97Hint='exposedField'/> 

<field name= 'rotation' type =' Rotation' vrml97Hint='exposedField'/> 

<field name='sensorRadius' type='Float' vrml97Hint='field'/> 

<field name= 'label' type='Strings'/> 

<field name='labelOffset' type='Vector3Float' vrml97Hint='exposedField'/> 

<field name='labelFontSize' type='Float' vrml97Hint=' field '/> 

<field name='labelColor' type='Color' vrml97Hint='exposedField7> 

</ExternProtoDeclare> 

<ExtemProtoDeclare n a m c =' W ay p o i n 11 n t e rp o 1 a to r ' nodeTypeHint= 'Group ' 

url=' " ../. ./T ools/Animation/W aypointlnterpolatorPrototype. wrl#W aypointlnterpolator 
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<../../Tools/Animation/W aypointInterpolatorPrototype.wrl> " 

'’ http://web.nps.navy.mi1/~brutzman/Savage/Tools/AnimationAVaypointInterpolatorPrototvpe.wrl#WaypointInterpolato 

r <http://web.nps.navv.mil/~brutzman/Savage/Tools/Animation/WavpointInterpolatorPrototype.wrl> " 

" . ./. ./Tools/Animation/W aypointlnterpolatorPrototype .xml#W ay pointlnterpolator 

<../../Tools/Animation/WavpointInterpolatorPrototype.xml> " 

" http://web.nps.navv.mi1/~brutzman/Savage/Tools/Animation/WaypointInterpolatorPrototvpe.xml#WaypointInterpolat 

or <http://web.nps.navv.mil/~brutzman/Savage/Tools/Animation/WavpointInterpolatorPrototype.xml> '"> 

<field name= 'wayPoints' type='Vector3FloatArray' vrml97Hint='field'/> 

<field name='pitchUpDownForVerticalWayPoints' type=' Boolean' vrml97Hint =' field '/> 

<!-- Priority of use: legSpeeds (m/sec), legDurations (seconds), defaultSpeed (m/sec) --> 

<!-- If used, array lengths for legSpeeds and legDurations must be one less than number of wayPoints. --> 

<field name=' legSpeeds' type='Floats ' vrml97Hint=' field 7> 

<field name= 'legDurations ' type='Times' vrml97Hint=' field' /> 

<field name= 'defaultSpeed' type='Float' vrml97Hint='field'/> 

<!-- turningRate (degrees/second) will also determine standoff distance prior to waypoint where turn 
commences. If 0, turns are instantaneous. --> 

<field name= 'turningRate' type='Float' vrml97Hint='field'/> 

<field name='totalDuration' type='Time' vrml97Hint='eventOut'/> 

<!-- exposed Positionlnterpolator and Orientationlnterpolator settings: --> 

<field name=' fraction' type='Float' vrml97Hint='eventIn'/> 

<field name='positionValue' type ='Vector3 Float' vnnl97Hint='eventOut'/> 

<field name='orientationValue ' type= 'Rotation' vrml97Hint='eventOut'/> 

<field name='lineColor' type='Color' vrml97Hint='exposedField'/> 

<!-- highlightSegmentColors must contain two color values, for each endpoint of the highlight segment. --> 

<field name=' highlightSegmentColors' type='Colors' IS='HighlightSegmentColorNode.color' 
vrml97Hint='exposedField'/> 

<field name= 'transparency' type='Float' vrml97Hint='exposedField'/> 

<field name=TabelOffset' type='Vector3Float' vrml97Hint='field'/> 

<field name='labelFontSize' type='Float' vrml97Hint=' field '/> 

<field name='labelColor' type='Color' vrml97Hint=' field '/> 
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<field name='traceEnabled' type= 'Boolean' vrml97Hint=' field '/> 


</ExternProtoDeclare> 

<ExtemProtoDeclare name='ViewPositionOrientation' 

url=' " ■■/■■/Tools/Authoring/ViewPositionOrientationPrototype.wrl#ViewPositionOrientation 

<../■ ./Tools/Authoring/ViewPositionOrientationPrototype.wrl> " 

" http://web.nps.navy.mi1/~brutzman/Savage/Tools/Authoring/ViewPositionOrientationPrototype.wrl#ViewPositionOri 

entation chttp://web.nps.navy.mil/~brutzman/Savage/Tools/Authoring/ViewPositionOrientationPrototype.wrl> " 

" ■■/■■/Tools/Authoring/ViewPositionOrientationPrototype.xml#ViewPositio nOrientation 

<../../Tools/Authoring/ViewPositionOrientationPrototype.xml> " 

" http://web.nps.navv.mi1/~brutzman/Savage/Tools/Authoring/ViewPositionOrientationPrototype.xml#ViewPositionOri 

entation <http://web.nps.navy.mil/~brutzman/Savage/Tools/Authoring/ViewPositionOrientationPrototype.xml> '”> 

<field name= 'enabled' type =' Boolean' vrml97Hint='exposedField7> 

</ExternProtoDeclare> 

<ExtemProtoDeclare name= ' CameraCompas s36 ' 

url=' " ■■/■■/Tools/HeadsUpDisplavs/CameraCompassPrototypes.wrl#CameraCompass36 

<../../Tools/HeadsUpDisplays/CameraCompassPrototypes.wrl> " 

" http://web.nps.navy.mi1/~brutzman/Savage/Tools/HeadsUpDisplays/CameraCompassPrototypes.wrl#CameraCompass 

36 <http://web.nps.navy.mil/~brutzman/Savage/Tools/HeadsUpDisplays/CameraCompassPrototypes.wri> " 

" ■■/■■/Tools/HeadsUpDisplavs/CameraCompassPrototypes.xml#CameraCompass36 

<../../Tools/HeadsUpDisplays/CameraCompassPrototypes.xml> " 

" http://web.nps.navy.mi1/~brutzman/Savage/Tools/HeadsUpDisplays/CameraCompassPrototypes.xml#CameraCompas 

s36 <http://web.nps.naw.mil/~brutzman/Savage/Tools/HeadsUpDisplavs/CameraCompassPrototypes.xml> '"> 

<field name= 'enabled' type =' Boolean' vrml97Hint='exposedField'/> 

<field name='positionOffsetFromCamera' type='Vector3Float' vrml97Hint='exposedField'/> 

<field name='markerColor' type='Color' vrml97Hint='exposedField'/> 

<field name='labelColor' type='Color' vrml97Hint='exposedField7> 

</ExternProtoDeclare> 
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<ExtemProtoDeclare name=' AH 1 SuperCobra' nodeTypeHint=' Group' url=' ./AircraftHelicopters/AH 1 SuperCobra- 
UnitedStates/S uperCobraPrototype.wrl#SuperCobra <../. ./AircraftHelicopters/AH lSuperCobra- 

UnitedStates/SuperCobraPrototype.wrl> '’ 

" http://web.nps.navy.mil/~brutzman/Savage/AircraftHelicopters/AHlSuperCobra- 

UnitedStates/SuperCobraPrototype.wrl#SuperCobra 

<http://web.nps.navy.mil/~brutzman/Savage/AircraftHelicopters/AHlSuperCobra- 

UnitedStates/SuperCobraPrototype.wrl> " ", ./. ./AircraftHelicopters/AH 1 SuperCobra- 
UnitedStates/SuperCobraPrototype.xml#SuperCobra ./AircraftHelicopters/AH 1 SuperCobra- 

UnitedStates/SuperCobraPrototype.xml> " 

" http ://web .nps .navy .mil/~brutzman/S av age/AircraftHelicopters/AH 1 SuperCobra- 

UnitedStates/SuperCobraPrototype.xml#SuperCobra 

<http: //web. nps. nav y .mil/~brutzman/S avage/AircraftHelicopters/AH 1 SuperCobra- 

UnitedStates/SuperCobraPrototype.xml> '"> 

<freld name='tailBoomColor' type='Node' vrml97Hint=' field '/> 

<field name='tailRotorDriveShaftColor' type='Node' vrml97Hint='field7> 

<field name='horizontalStabilizerColor' type='Node' vrml97Hint='field'/> 

<field name='fuselageColor' type='Node' vrml97Hint='field'/> 

<field name='cockpitColor' type='Node' vrml97Hint=' field '/> 

<field name='cowlingColor' type='Node' vrml97Hint=' field' /> 

<field name='helicopterName' type='String' vrml97Hint='field'/> 

<field name='inFlight' type=' Boolean' vrml97Hint='eventIn'/> 

</ExternProtoDeclare> 

<!-- ================= ~> 

<NavigationInfo avatarSize ='2 2 2' speed='100' type='EXAMINE ANY visibilityLimit='60000'/> 

<Background groundAngle=' 1.309, 1.571 ' groundColoi^'O 0.2 0.4, 0.05 0.25 0.6, 0.1 0.2 0.4' skyAngle=' 1.309, 1.571' 
skyColor^'0.1 0.1 0.4, 0.1 0.125 0.4, 0.1 0.1 0.3 '/> 

<Viewpoint description^ Amphibious raid - full scenario seen from above' orientation='-0.557 -0.799 -0.229 0.9506' 
position='-600 10000 25000'/> 

<Viewpoint description^' 1000m elevation view' orientation='0 1 0 -0.78' position='-200 1000 22000'/> 
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<Transform rotation='0 0 1 .1 ’> 


cViewpoint description='Waypoint' orientation='0 1 0 1.57' position='9451 20 14935 7> 
<Viewpoint description^ waypoint 2' orientation='() 1 0 1.57' positional 1217.2 10.0 13996. 6'/> 

</Transform> 

<!-- ViewPositionOrientation is a prototype lets us find good viewpoints for inclusion in the scene --> 
<ProtoInstance name='ViewPositionOrientation'> 

<fieldValue name =' enabled' value='true'/> 

</ProtoInstance > 

<!-- This is a hack to orient camera to scene. Actually, scene elements need to be rotated. --> 
cTransform rotation='0 1 0 1.57'> 

<ProtoInstance name='CameraCompass36'> 

<fieldValue name= 'enabled' value='tme'/> 

<fieldValue name='positionOffsetFromCamera' value='0 5 0'/> 

<fieldValue name='markerColor' value='0.9 0.9 0.9 '/> 

<fieldValue name='labelColor' value='0.9 0.9 0.9 '/> 

</ProtoInstance> 

</Transform> 

<ProtoInstance DEF='CobraCapStartingPoint' name='HiddenViewpoint'> 

<fieldValue name='position' value='6530 18 16800'/> 

<fieldValue name= 'rotation' value='0 1 0 -0.1 '/> 

<fieldValue name='sensorRadius ' value='1007> 

<fieldValue name=' label' value= '"Cobra CAP" "starting point" "" "6530 11.5 16800"’/> 
<fieldValue name='labelOffset' value='0 -2 0'/> 

<fieldValue name='labelFontSize' value='0.5'/> 
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<fieldValue name='labelColor' value='l 0.5 0'/> 


</ProtoInstance> 

<ProtoInstance DEF='CobraCapInitialClimb' name='HiddenViewpoint '> 

<fieldValue name= 'position' value='6530 500 16800 '/> 

<fieldValue name= 'rotation' value='0 1 0 -0.4'/> 

<fieldValue name='sensorRadius ' value='100'/> 

<fieldYalue name='label’ value='"Cobra CAP" "initial climb point.6530 500 16800"'/> 

<fieldValue name='labelOffset' value='0 1 0'/> 

<fieldValue name='labelFontSize' value='0.5'/> 

<fieldValue name='labelColor' value='l 0.5 0 '/> 

</ProtoInstance> 

<ProtoInstance DEF='SouthemCapTurnPoint' name='HiddenViewpoint'> 

<fieldValue name= 'position' value='25400 500 19100 '/> 

<fieldValue name= 'rotation' value='0 1 0 0.4'/> 

<fieldValue name='sensorRadius' value='200'/> 

<fieldValue name='label' value='"Cobra CAP" "Southern Turn Point.25400 500 191000"'/> 

<fieldValue name='labelOffset' value='0 1 0'/> 

<fieldValue name='labelFontSize' value='0.5'/> 

<fieldValue name='labelColor' value='l 0.5 0 '/> 

</ProtoInstance > 

<ProtoInstance DEF='NorthemCapTurnPoint ' name='HiddenViewpoint'> 

<fieldValue name='position' value='5100 500 700 '/> 

<fieldValue name= 'rotation' value='0 1 0 -2.3 '/> 

<fieldValue name='sensorRadius ' value='200'/> 

<fieldValue name=Tabel' value='"Cobra CAP" "Northern Turn Point" "" "5100 500 700"' /> 
<fieldValue name='labelOffset' value='0 1 0'/> 
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<fieldValue name='labelFontSize' value='0.5'/> 

<fieldValue name='labelColor' value='l 0.5 ()'/> 

</ProtoInstance> 

<S witch whichChoice='0'> 

<!-- Main group with all players. --> 

<Group DEF='EntireScene'> 

<!-- ==================== Land terrain ==================== --> 

<Transform> 

<Inline 

url=' " <. ./. ■/Locations/CampPendletonCalifornia/CampPendletonOperatingAreasExample. wrl> " 

'’ <http://web.nps.navy.mil/~brutzman/Savage/Locations/CampPendletonCalifornia/CampPendlet 

onQperatingAreasExample. wrl> " 

" <. ./. ■/Locations/CampPendletonCalifornia/CampPendletonOperatingAreasExample.xml> " 

" <http://web.nps.navy.mil/~brutzman/Savage/Locations/CampPendletonCalifornia/CampPendlet 

onOperatingAreasExample.xml> "7> 

</Transform> 

<!-- ==================== Ships ==================== --> 

<!-- LPD is anchored and not moving. --> 

<TransformDEF='LPD' translation='6600 10 16800 '> 

<Inline url= ' "<../. ■/Ships/LandingPlatformDock-LPD/LPD.wrl> " 

" <http ://web .nps .navy .mil/~brutzman/S avage/Ships/LandingPlatformDock- LPD/LPD. wrl> " 

" <. ./. ■/Ships/LandingPlatformDock-LPD/LPD.xml> " 

" <http://web.nps.navy ■mil/~brutzman/Savage/Ships/LandingPlatformDock-LPD/LPD.xml> "7> 

</Transform> 

<!-- ==================== Amphibious vehicles ==================== --> 

<!— AAAV-1 Block-> 
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cTimeSensor DEF='AAAVl_Clock' loop='true'/> 

<ROUTE fromNode='AAAVl_Clock' fromField='fraction_changed' 
toNode='AAAV_l_WaypointInterpolator' toField='fraction'/> 

<ROUTE fromN ode= ' A A A V_ 1 _W aypointlnterpolator' fromField =' totalD urati on' 
toNode='AAAV l_Clock' toField='cycleInterval'/> 

<ProtoInstance DEF='AAAV_l_WaypointInterpolator' name='WaypointInterpolator'> 

<!-- need to improve elevations on beach (final waypoint) --> 

<fieldValue name=' wayPoints' value='6802 1 16343 7685.0 1.0 15873.7, 8568.1 1.0 15404.4, 
9451.1 1.0 14935.2, 10334.2 1.0 14465.9, 11217.2 1.0 13996.6, 12100.3 1.0 13527.3, 12983.3 
1.0 13058.0, 13866.4 1.0 12588.7, 14749.4 1.0 12119.5, 15632.5 1.0 11650.2, 16515.5 1.0 
11180.9, 17398.6 1.0 10711.6, 18281.6 1.0 10242.3, 19164.7 1.0 9773.1, 19400.0 1.0 9648.0, 

19782 1 9185 20100 10 8800'/> 

<!-- 1 knot = 0.514444444 meters/second --> 

<fieldValue name='defaultSpeed' value ='50 7> 

<fieldValue name='lineCobr' value='0.8 0.8 0'/> 

<fieldValue name='labelColor' value='0.8 0.8 0'/> 

<fieldValue name='labelOffset' value='0 3 0'/> 

<fieldValue name='labelFontSize' value='1.5'/> 

<fieldValue name='traceEnabled' value =' false '/> 

</ProtoInstance > 

<ROUTE fromNode='AAAV_l_WaypointInterpolator' fromField='positionValue' toNode='AAAV- 
Focation' toField=' set_translation'/> 

<ROUTE fromNode='AAAV_l_WaypointInterpolator' fromField =' orientation Value' toNode='AAAV- 
Focation' toField=' set_rotation'/> 

<!-- Most entity transforms will get converted to DIS-Java-VRMF EspduTransforms when creating a 
networked DIS version. --> 
cTransform translation '6600 0 16800'/> 

<EspduTransformDEF='AAAV-Focation' readlnterval='0' traceOffset='0 4 O' traceSize='2 2 2' 
translatior^'6600 0 16800' writelnterval='l'> 
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<Group> 


cViewpoint dcscriptioii=' AAAV raid from behind' orientation='0 1 0 -1.57' 
position='-40 2 0'/> 

<Viewpoint description^ AAA V raid from ahead' orientation='0 1 0 1.57' position='50 
12 0 '/> 

<TransformDEF='VerticalCorrection' translation='0 -4 0'> 

<Inline DEF='AAAV' 

url=' " <. ./. ./Amphibious Vehicles/AAAV/AAAV.wrl> " 

'’ <http://web.nps.navv.mil/~brutzman/Savage/AmphibiousVehicles/AAAV/AAA 

V.wrl> " "<. ./. ./AmphibiousVehicles/AAAV/AAAV.xml> " 
" <http://web.nps.navy.mil/~brutzman/Savage/AmphibiousVehicles/AAAV/AAA 

V.xml>"'/> 


</Transform> 

<Group DEF='OtherAAAVs'> 

<Transform translation '-15 -4 15 '> 

<Transform DEF=' AAAV-2'> 

<Inline USE='AAAV'/> 

<PositionInterpolator DEF='AAV-2PATH' key='0.00, 0.11, 0.17, 
0.22, 0.33, 0.44, 0.50, 0.55, 0.66, 0.77, 0.83, 0.88, 0.99' 
keyValue='0.0 0.0 0.0, 1.0 0.96 1.0, 1.5 0.21 1.5, 2.0 0.96 2.0, 3.0 
0.0 3.0, 2.5 0.96 3.0, 1.75 0.41 3.0, 1.0 0.96 3.0, 3.0 0.0 3.0, 2.0 
0.46 2.0, 1.0 0.4 1.5, 0.0 0.46 1.0, 0.0 0.0 0.0'/> 

<ROUTE fromNode='AAV-2PATH' fromField='value_changed' 
toN ode= ' A A A V - 2 ' toField =' set_translation' /> 

</Transform> 
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</Transform> 

<Transform translation^'- 15 -4 -17.5 ’> 

<Transform DEF=' AAAV-3'> 

<Inline USE='AAAV'/> 

<PositionInterpolator DEF='AAV-3PATH' key='0.00, 0.07, 0.13, 
0.22, 0.36, 0.47, 0.55, 0.625, 0.66, 0.72, 0.80, 0.85, 0.99' 
keyValue='0.0 0.0 0.0, 1.0 0.96 1.0, 1.5 0.21 2.25, 2.0 0.46 2.66, 
3.0 -0.25 3.0, 2.5 0.96 3.0, 1.75 0.41 3.0, 1.0 0.96 3.0, 3.0 0.0 3.0, 
2.0 0.46 2.0, 1.0 0.4 1.5, 0.0 0.46 1.0, 0.0 0.0 0.0'/> 

<ROUTE fromNode='AAV-3PATH' fromField='value_changed' 
toNode='AAAV-3' toField='set_translation7> 

</Transform> 

</Transform> 

</Group> 

</Group> 

</EspduTransform> 

<!-- ==================== Helicopter 1 Block ==================== --> 

<TransformDEF='Helo-l' translation='6530 11.5 16800'> 

<ProtoInstance DEF='HeloInstancel ' name='AHlSuperCobra'> 

<fieldValue name='helicopterName' value='Cobra CAP l'/> 
<fieldValue name='tailBoomColor'> 

<Appearance DEF=' GREY_APPEARAN CE'> 

<MaterialdiffuseColor='0.5 0.5 0.5 '/> 
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</Appearance> 

</fieldValue> 

<fieldValue name= 'tailRotorDriveShaftColor '> 

<Appearance US 11=' GREY_APPEARANCE' /> 
</fieldValue> 

<fieldValue name= ' horizontalStabilizerColor'> 
<Appearance> 

<MaterialdiffuseColor='0.5 0.5 0.5 '/> 
</Appearance> 

</fieldValue> 

<fieldValue name= ' fuselageColor'> 

<Appearance> 

<MaterialdiffuseColor='0.6 0.6 0.6'/> 
</Appearance> 

</fieldValue> 

<fieldValue name='cockpitColor'> 

<Appearance> 

<MaterialdiffuseColor='0.6 0.6 0.6'/> 
</Appearance> 

</fieldValue> 
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<fieldValue name='cowlingColor'> 

<Appearance> 

<MaterialdiffuseColor='0.5 0.5 0.5 '/> 
</Appearance> 

</fieldValue> 

<fieldValue name='inFlight' value=' false '/> 
</ProtoInstance > 


</Transform> 

<ProtoInstance DEF='Helo_l_WaypointInterpolator' name='WaypointInterpolator'> 


<fieldValue name=' wayPoints' value='6600 600 16800 7592.6 600 16921.4 8585.2 600 

17042.9 9577.8 600 17164.3 10570.4 600 17285.7 11563.0 600 17407.2 12555.6 600 17528.6 

13548.2 600 17650.0 14540.8 600 17771.5 15533.4 600 17892.9 16526.0 600 18014.4 17518.6 
600 18135.8 18511.2 600 18257.2 19503.8 600 18378.7 20496.4 600 18500.1 21489.0 600 
18621.5 22481.6 600 18743.0 23474.2 600 18864.4 24466.8 600 18985.8 25400 600 19100 

24906.2 600 18230.4 24412.4 600 17360.9 23918.5 600 16491.3 23424.7 600 15621.8 22930.9 
600 14752.2 22437.1 600 13882.6 21943.2 600 13013.1 21449.4 600 12143.5 20955.6 600 

11273.9 20800 600 11000 20072.7 600 10313.7 19345.4 600 9627.4 18618.1 600 8941.0 
17890.8 600 8254.7 17163.5 600 7568.4 16436.2 600 6882.1 15708.9 600 6195.7 14981.6 600 

5509.4 14254.3 600 4823.1 13700 600 4300 12777.6 600 3913.9 11855.1 600 3527.7 10932.7 
600 3141.6 10010.2 600 2755.4 9087.8 600 2369.3 8165.4 600 1983.2 7242.9 600 1597.0 6320.5 
600 1210.9 5398.0 600 824.8 5100 600 700 5192.8 600 1695.7 5285.5 600 2691.4 5378.3 600 
3687.1 5471.1 600 4682.8 5563.8 600 5678.4 5656.6 600 6674.1 5749.4 600 7669.8 5842.1 600 

8665.5 5934.9 600 9661.2 6027.7 600 10656.9 6120.4 600 11652.6 6213.2 600 12648.3 6306.0 
600 13643.9 6398.7 600 14639.6 6491.5 600 15635.3 6584.3 600 16631.0 6600 600 16800'/> 
<!-- 1 knot = 0.514444444 meters/second --> 

<fieldValue name='defaultSpeed' value='100'/> 


231 


<fieldValue name='pitchUpDownForVerticalWayPoints' value='false '/> 
<fieldValue name='lineColor' value='() 0.8 0'/> 

<fieldValue name='labelColor' value='0 0.8 0 '/> 

<fieldValue name='labelOffset' value='0 5 0'/> 

<fieldValue name='labelFontSize' value='3'/> 

<fieldValue name='traceEnabled' value =' false '/> 

</ProtoInstance> 

<TimeSensor DEF='Helol_Clock' loop='trae'/> 

<!-- ==================== Helicopter 2 Block ==================== --> 

<TransformDEF='Helo-2' translation='6600 50 16800 '> 

<Transform> 

<ProtoInstance DEF='HeloInstance2' name='AHlSuperCobra'> 

<fieldValue name='helicopterName' value='Cobra CAP 2 '/> 
<fieldValue name='tailBoomColor'> 

<Appearance> 

<MaterialdiffuseColor='0.5 0.5 0.5 '/> 

</Appearance> 

</fieldValue> 

<fieldValue name= 'tailRotorDriveShaftColor '> 

<Appearance> 

<MaterialdiffuseColor='0.5 0.5 0.5 '/> 

</Appearance> 


232 






</fieldValue> 

<fieldValue name= ' horizontalStabilizerColor'> 
<Appearance> 

<MaterialdiffuseColor='0.5 0.5 0.5 '/> 
</Appearance> 

</fieldValue> 

<fieldValue name= ' fuselageColor'> 

<Appearance> 

<MaterialdiffuseColor='0.6 0.6 0.6'/> 
</Appearance> 

</fieldValue> 

<fieldValue name='cockpitColor'> 

<Appearance> 

<MaterialdiffuseColor='0.6 0.6 0.6'/> 
</Appearance> 

</fieldValue> 

<fieldValue name='cowlingColor'> 

<Appearance> 

<MaterialdiffuseColor='0.5 0.5 0.5 '/> 
</Appearance> 
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</fieldValue> 

<fieldValue name='inFlight' value='true'/> 
</ProtoInstance > 

</Transform> 


</Transform> 

<ProtoInstance DEF='Helo_2_WaypointInterpolator' name='WaypointInterpolator'> 


<fieldValue name= 'wayPoints' value='6530 11.5 16800 6530 500 16800 6600 500 
16800 7592.6 500 16921.4 8585.2 500 17042.9 9577.8 500 17164.3 10570.4 500 17285.7 
11563.0 500 17407.2 12555.6 500 17528.6 13548.2 500 17650.0 14540.8 500 17771.5 15533.4 
500 17892.9 16526.0 500 18014.4 17518.6 500 18135.8 18511.2 500 18257.2 19503.8 500 

18378.7 20496.4 500 18500.1 21489.0 500 18621.5 22481.6 500 18743.0 23474.2 500 18864.4 

24466.8 500 18985.8 25400 500 19100 24906.2 500 18230.4 24412.4 500 17360.9 23918.5 500 

16491.3 23424.7 500 15621.8 22930.9 500 14752.2 22437.1 500 13882.6 21943.2 500 13013.1 

21449.4 500 12143.5 20955.6 500 11273.9 20800 500 11000 20072.7 500 10313.7 19345.4 500 

9627.4 18618.1 500 8941.0 17890.8 500 8254.7 17163.5 500 7568.4 16436.2 500 6882.1 

15708.9 500 6195.7 14981.6 500 5509.4 14254.3 500 4823.1 13700 500 4300 12777.6 500 

3913.9 11855.1 500 3527.7 10932.7 500 3141.6 10010.2 500 2755.4 9087.8 500 2369.3 8165.4 
500 1983.2 7242.9 500 1597.0 6320.5 500 1210.9 5398.0 500 824.8 5100 500 700 5192.8 500 
1695.7 5285.5 500 2691.4 5378.3 500 3687.1 5471.1 500 4682.8 5563.8 500 5678.4 5656.6 500 
6674.1 5749.4 500 7669.8 5842.1 500 8665.5 5934.9 500 9661.2 6027.7 500 10656.9 6120.4 500 
11652.6 6213.2 500 12648.3 6306.0 500 13643.9 6398.7 500 14639.6 6491.5 500 15635.3 
6584.3 500 16631.0 6600 500 16800'/> 

<!-- 1 knot = 0.514444444 meters/second --> 

<fieldValue name='defaultSpeed' value='200'/> 

<fieldValue name='lineColor' value ='0.8 0 0'/> 

<fieldValue name='labelColor' value='0.8 0 0'/> 

<fieldValue name='iabelOffset' value='0 5 0'/> 

<fieldValue name='labelFontSize' value='37> 
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<fieldValue name='traceEnabled' value =' false '/> 


</ProtoInstance> 

<TimeSensor DEF='Helo2_Clock' loop='true'/> 

<!-- ============== AAV7PA1 -> 

<TransformDEF='AAV7PAlLocation' scale='1.25 1.25 1.25' translation='6620 -2 16900'> 

<Inline url=" ’<../../AmphibiousVehicles/ AAV/AAV.wrl> " 
'’ <http://web.nps.navy.mil/~brutzman/Savage/AmphibiousVehicles/AAV/AAV.wrl> '’ 

" <. ./. ./AmphibiousVehicles/AAV/AAV.xml> " 

" <http://web.nps.navy.mil/~brutzman/Savage/AmphibiousVehicles/AAV/AAV.xml> "7> 

</Transform> 

<ProtoInstance DEF='AAV7PAlWaypointInterpolator' name='WaypointInterpolator'> 

<fieldValue name='wayPoints' value='6620 -1 16900 6720 -1 16900 6870 -1 19500 
7400-1 19500 8400-1 16900 6620-1 16900'/> 

<!-- 1 knot = 0.514444444 meters/second --> 

<fieldValue name='defaultSpeed' value='5'/> 

<fieldValue name='lineColor' value='0.8 0 0.65 V> 

<fieldValue name='labelColor' value='0.8 0 07> 

<fieldValue name='labelOffset' value='0 5 0'/> 

<fieldValue name='labelFontSize' value='3'/> 

<fieldValue name =' traceEnabled ' value =' false '/> 

</ProtoInstance> 

<TimeSensor DEF='AAV7PA1 Clock' loop =' true '/> 

</Group> 

<!-- hide things here until ready to bring them into the active scene --> 

<S witch whichChoice='0'> 

<!-- Ocean bathymetry --> 
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<Transform rotation='0 1 0 1.5708' translation^ 11900 0 6000'> 


dnline ui l-"'<../../Locations/CampPcndlctonCalifornia/ChartlctTranscribcd.wrl>" 
'’ <http://web.nps.navy.mil/~brutzman/Savage/Locations/CampPendletonCalifornia/ChartletTrans 

cribed.wrl> " "<../. ■/Locations/CampPendletonCalifomia/ChartletTranscribed.xml> " 
" <http://web.nps.navy.mil/~brutzman/Savage/Locations/CampPendletonCalifomia/ChartletTrans 

cribed.xml> "7> 

</Transform> 

<!-- GeoViml versions will be here someday --> 

<Group> 


<!-- Southwest comer reference point: 33:12N 117:38W --> 

<!-- GeoLocation and USE EntireScene to follow --> 

</Group> 

</Switch> 

</Switch> 

<!-- AAAV-1 Waypoint Routes --> 

<!-- Helo-1 Waypoint Routes --> 

<ROUTE fromNode='Helol_Clock' fromField='isActive' toNode='HeloInstancel ' toField='inFlight7> 
<ROUTE fromNode='Helo_l_WaypointInterpolator' fromField='totalDuration' toNode='Helol_Clock' 
toField= 'cycleInterval'/> 

<ROUTE fromNode='Helol_Clock' fromField='fraction_changed' toNode='Helo_l_WaypointInterpolator' 
toField= ' fraction'/> 

<ROUTE fromNode='Helo_l_WaypointInterpolator' fromField='positionValue' toNode='Helo-l' 
toField= 'set_translation'/> 

<ROUTE fromNode='Helo_l_WaypointInterpolator' fromField='orientationValue' toNode=' Helo-1' 
toField= 'set_rotation'/> 

<!-- Helo-2 Waypoint Routes --> 
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<ROUTE fromNode='Helo2_Clock' fromField=' is Active ' toNode='HeloInstance2' toField='inFlight'/> 

<ROUTE fromNode='FIelo_2_WaypointInterpolator' fromField='totalDuration' toNode='Helo2_Clock' 
toField= 'cycleInterval'/> 

<ROUTE fromNode='Helo2_Clock' fromField='fraction_changed' toNode='Helo_2_WaypointInterpolator' 
toField= ' fraction' /> 

<ROUTE fromNode='Helo_2_WaypointInterpolator' fromField='positionValue ' toNode='Helo-2' 
toField= 'set_translation'/> 

<ROUTE fromNode='FIelo_2_WaypointInterpolator' fromField='orientationValue' toNode='FIelo-2' 
toField= 'set_rotation'/> 

<!-- AAV2 -> 

<ROUTE fromNode='AAAVl_Clock' fromField='fraction_changed' toNode='AAV-2PATH' toField='set_fraction'/> 
<!-- AAV7PA1 Waypoint Routes --> 

<ROUTE fromNode='AAV7PAlWaypointInterpolator' fromField='totalDuration' toNode='AAV7PAlClock' 
toField= 'cyclelnterval7> 

<ROUTE fromNode='AAV7PAlClock' firomField='fraction_changed' toNode='AAV7PAlWaypointInterpolator' 
toField= ' fraction' /> 

<ROUTE fromNode='AAV7PAlWaypointInterpolator' fromField='positionValue' toNode='AAV7PAl Location' 
toField= 'set_translation'/> 

<ROUTE fromNode='AAV7PAlWaypointInterpolator' fromField='orientationValue ' toNode=' AAV7PAlLocation' 
toField= 'set_rotation'/> 

</Scene> 

</X3D> 

<!-- Tag color codes: <NodeName attribute=' value '/> --> 
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